Skip to content

chore(libdd-data-pipeline): solve cargo deny [APMSP-3884] - #2318

Open
Eldolfin wants to merge 6 commits into
mainfrom
oscarld/solve-cargo-deny-on-libdd-data-pipeline
Open

chore(libdd-data-pipeline): solve cargo deny [APMSP-3884]#2318
Eldolfin wants to merge 6 commits into
mainfrom
oscarld/solve-cargo-deny-on-libdd-data-pipeline

Conversation

@Eldolfin

@Eldolfin Eldolfin commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Solve cargo deny errors in libdd-data-pipeline by updating some dependencies.

Motivation

What inspired you to submit this pull request?

Additional Notes

Sadly, updating time requires a bump in our MSRV from 1.87.0 to 1.88.0, this can be done in a separate PR.

How to test the change?

Describe here in detail how the change can be validated.

@datadog-prod-us1-4

datadog-prod-us1-4 Bot commented Aug 5, 2026 •
edited
Loading

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 76.59% (+0.03%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 68f79be | Docs | View more details | Give us feedback!

@Eldolfin
ignore RUSTSEC-2026-0009 until MSRV bump
2021264 
We cannot update `time` before bumping our MSRV.

Also we're not affected by this because there is no user provided input
@dd-octo-sts

dd-octo-sts Bot commented Aug 5, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 89.48 MB 89.47 MB -0% (-5.43 KB) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.20 MB 8.20 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.06 MB 11.06 MB -0% (-424 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 100.66 MB 100.66 MB -0% (-616 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 26.62 MB 26.62 MB --.02% (-6.50 KB) 💪
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 94.56 KB 94.56 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 180.67 MB 180.61 MB --.03% (-64.00 KB) 💪
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 772.61 MB 771.59 MB --.13% (-1.02 MB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.72 MB 8.72 MB +0% (+512 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 94.56 KB 94.56 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 25.64 MB 25.64 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 51.06 MB 51.07 MB +.01% (+9.84 KB) 🔍
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.20 MB 23.19 MB --.03% (-9.50 KB) 💪
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 96.04 KB 96.04 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 185.61 MB 185.55 MB --.03% (-64.00 KB) 💪
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 759.02 MB 758.15 MB --.11% (-895.16 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.74 MB 6.74 MB +0% (+512 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 96.04 KB 96.04 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 27.58 MB 27.58 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 48.60 MB 48.60 MB +0% (+2.33 KB) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 79.75 MB 79.73 MB --.01% (-12.04 KB) 💪
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.15 MB 9.15 MB --.04% (-4.00 KB) 💪
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 95.39 MB 95.38 MB -0% (-3.84 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.16 MB 11.17 MB +.03% (+3.87 KB) 🔍

@pr-commenter

pr-commenter Bot commented Aug 5, 2026 •
edited
Loading

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-08-20 17:38:29

Comparing candidate commit 68f79be in PR branch oscarld/solve-cargo-deny-on-libdd-data-pipeline with baseline commit 8563c07 in branch main.

Found 17 performance improvements and 7 performance regressions! Performance is the same for 144 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:credit_card/is_card_number/ 3782-8224-6310-005

  • 🟩 execution_time [-4.860µs; -4.606µs] or [-6.086%; -5.767%]
  • 🟩 throughput [+768346.822op/s; +812100.867op/s] or [+6.136%; +6.486%]

scenario:credit_card/is_card_number/ 378282246310005

  • 🟩 execution_time [-5.301µs; -5.207µs] or [-7.258%; -7.129%]
  • 🟩 throughput [+1051980.903op/s; +1069825.328op/s] or [+7.684%; +7.814%]

scenario:credit_card/is_card_number/378282246310005

  • 🟩 execution_time [-5.202µs; -5.124µs] or [-7.459%; -7.347%]
  • 🟩 throughput [+1138053.625op/s; +1154227.868op/s] or [+7.937%; +8.050%]

scenario:credit_card/is_card_number/37828224631000521389798

  • 🟩 execution_time [-6.979µs; -6.938µs] or [-13.351%; -13.273%]
  • 🟩 throughput [+2928080.906op/s; +2947427.262op/s] or [+15.306%; +15.407%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

  • 🟩 execution_time [-5.549µs; -5.491µs] or [-9.465%; -9.366%]
  • 🟩 throughput [+1764105.293op/s; +1781289.390op/s] or [+10.343%; +10.443%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

  • 🟩 execution_time [-5.687µs; -5.640µs] or [-10.236%; -10.152%]
  • 🟩 throughput [+2035343.160op/s; +2051121.002op/s] or [+11.307%; +11.394%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟩 execution_time [-6.995µs; -6.947µs] or [-13.381%; -13.288%]
  • 🟩 throughput [+2931970.188op/s; +2955212.888op/s] or [+15.327%; +15.449%]

scenario:datadog_sample_span/name_pattern_rule_not_matching/wall_time

  • 🟥 execution_time [+7.313ns; +7.434ns] or [+4.655%; +4.732%]

scenario:datadog_sample_span/unicode_uppercase_service_rule/wall_time

  • 🟩 execution_time [-15.660ns; -15.458ns] or [-4.452%; -4.394%]

scenario:glob_matcher/ascii_exact_miss/wall_time

  • 🟥 execution_time [+0.651ns; +0.721ns] or [+5.572%; +6.170%]

scenario:glob_matcher/ascii_pattern_unicode_subject/wall_time

  • 🟥 execution_time [+11.383ns; +11.486ns] or [+8.344%; +8.419%]

scenario:glob_matcher/unicode_pattern_wildcard_match/wall_time

  • 🟥 execution_time [+6.558ns; +6.668ns] or [+5.161%; +5.247%]

scenario:profiler_attached/fast_path_system/4096

  • 🟩 execution_time [-8.221ns; -8.082ns] or [-7.831%; -7.699%]

scenario:profiler_attached/slow_path_system/4096

  • 🟥 execution_time [+10.101ns; +10.191ns] or [+6.993%; +7.055%]

scenario:sql/obfuscate_sql_string

  • 🟩 execution_time [-17.330µs; -17.088µs] or [-5.631%; -5.553%]

scenario:trace_buffer/4_senders/no_delay

  • 🟥 execution_time [+259.058µs; +284.912µs] or [+11.136%; +12.247%]
  • 🟥 throughput [-171991.894op/s; -155265.434op/s] or [-11.100%; -10.020%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@Eldolfin
Eldolfin marked this pull request as ready for review August 5, 2026 14:58
@Eldolfin
Eldolfin requested a review from a team as a code owner August 5, 2026 14:58
@Eldolfin

Eldolfin commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

@codex review

chatgpt-codex-connector[bot]
chatgpt-codex-connector Bot reviewed Aug 5, 2026
View reviewed changes

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 202126436a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread Cargo.lock
Comment thread Cargo.lock
@Eldolfin
Eldolfin requested review from a team as code owners August 6, 2026 12:58
@Eldolfin
Eldolfin requested review from mabdinur and removed request for a team August 6, 2026 12:58
@github-actions

github-actions Bot commented Aug 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 8371 documentation warning(s) found

📦 datadog-sidecar - 2929 warning(s)

📦 libdd-common - 169 warning(s)

📦 libdd-crashtracker - 1156 warning(s)

📦 libdd-data-pipeline - 1282 warning(s)

📦 libdd-ddsketch - 8 warning(s)

📦 libdd-library-config - 265 warning(s)

📦 libdd-profiling - 650 warning(s)

📦 libdd-trace-normalization - 244 warning(s)

📦 libdd-trace-stats - 904 warning(s)

📦 libdd-trace-utils - 764 warning(s)

Updated: 2026-08-20 16:55:09 UTC | Commit: d271a73 | missing-docs job results

@github-actions

github-actions Bot commented Aug 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

⚠️ 22 issue(s) found, showing only errors (advisories, bans, sources)

📦 datadog-sidecar - 4 error(s)

Show output 
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:37:1
   │
37 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     ├── datadog-sidecar v0.0.1
     ├── (dev) libdd-ffe v1.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v0.1.0
         └── datadog-sidecar v0.0.1 (*)

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:92:1
   │
92 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── datadog-live-debugger v0.0.1
                     │   │   └── datadog-sidecar v0.0.1
                     │   ├── datadog-sidecar v0.0.1 (*)
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-crashtracker v2.0.0
                     │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   └── libdd-crashtracker-ffi v41.0.0
                     │   │   │       └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-data-pipeline v8.0.0
                     │   │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   │   └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── (dev) libdd-ffe v1.0.0
                     │   │   │   └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-remote-config v3.0.0
                     │   │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── libdd-ffe v1.0.0 (*)
                     │   │   │   └── (dev) libdd-remote-config v3.0.0 (*)
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v7.0.0
                     │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │       ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   │       └── libdd-ipc v0.1.0
                     │   │   │   │           └── datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── libdd-crashtracker v2.0.0 (*)
                     │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-trace-stats v7.0.0 (*)
                     │   │   └── libdd-trace-utils v10.1.0
                     │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │       ├── libdd-data-pipeline v8.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v6.0.0
                     │   │       │   └── libdd-trace-stats v7.0.0 (*)
                     │   │       ├── libdd-trace-stats v7.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
                     │   ├── libdd-common-ffi v41.0.0
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   └── libdd-crashtracker-ffi v41.0.0 (*)
                     │   ├── (build) libdd-crashtracker v2.0.0 (*)
                     │   ├── libdd-crashtracker-ffi v41.0.0 (*)
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   ├── libdd-dogstatsd-client v5.0.0 (*)
                     │   ├── libdd-ffe v1.0.0 (*)
                     │   ├── libdd-ipc v0.1.0 (*)
                     │   ├── libdd-remote-config v3.0.0 (*)
                     │   ├── libdd-shared-runtime v3.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   ├── libdd-trace-obfuscation v6.0.0 (*)
                     │   ├── libdd-trace-stats v7.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-crashtracker v2.0.0 (*)
                     ├── (dev) libdd-data-pipeline v8.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   ├── libdd-ipc v0.1.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v7.0.0 (*)
                     ├── (dev) libdd-ipc v0.1.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.1
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-trace-obfuscation v6.0.0 (*)
                     ├── (dev) libdd-trace-stats v7.0.0 (*)
                     └── (dev) libdd-trace-utils v10.1.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:154:1
    │
154 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      └── hyper v1.6.0
          ├── httpmock v0.8.0-alpha.1
          │   ├── (dev) datadog-sidecar v0.0.1
          │   ├── (dev) libdd-data-pipeline v8.0.0
          │   │   ├── datadog-live-debugger v0.0.1
          │   │   │   └── datadog-sidecar v0.0.1 (*)
          │   │   └── datadog-sidecar v0.0.1 (*)
          │   ├── (dev) libdd-ffe v1.0.0
          │   │   └── datadog-sidecar v0.0.1 (*)
          │   ├── (dev) libdd-telemetry v7.0.0
          │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   ├── libdd-crashtracker v2.0.0
          │   │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   │   └── libdd-crashtracker-ffi v41.0.0
          │   │   │       └── datadog-sidecar v0.0.1 (*)
          │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │   │   └── libdd-trace-stats v7.0.0
          │   │       ├── datadog-sidecar v0.0.1 (*)
          │   │       ├── libdd-data-pipeline v8.0.0 (*)
          │   │       └── libdd-ipc v0.1.0
          │   │           └── datadog-sidecar v0.0.1 (*)
          │   ├── (dev) libdd-trace-stats v7.0.0 (*)
          │   └── libdd-trace-utils v10.1.0
          │       ├── (dev) datadog-sidecar v0.0.1 (*)
          │       ├── libdd-data-pipeline v8.0.0 (*)
          │       ├── libdd-trace-obfuscation v6.0.0
          │       │   └── libdd-trace-stats v7.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── (dev) libdd-trace-utils v10.1.0 (*)
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v5.2.0
          │       ├── datadog-live-debugger v0.0.1 (*)
          │       ├── datadog-sidecar v0.0.1 (*)
          │       ├── libdd-capabilities-impl v4.0.0
          │       │   ├── datadog-live-debugger v0.0.1 (*)
          │       │   ├── datadog-sidecar v0.0.1 (*)
          │       │   ├── libdd-crashtracker v2.0.0 (*)
          │       │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   ├── (dev) libdd-ffe v1.0.0 (*)
          │       │   ├── libdd-remote-config v3.0.0
          │       │   │   ├── datadog-live-debugger v0.0.1 (*)
          │       │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
          │       │   │   ├── libdd-ffe v1.0.0 (*)
          │       │   │   └── (dev) libdd-remote-config v3.0.0 (*)
          │       │   ├── libdd-shared-runtime v3.0.0
          │       │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   │   ├── libdd-dogstatsd-client v5.0.0
          │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
          │       │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   │   │   └── libdd-trace-stats v7.0.0 (*)
          │       │   │   ├── libdd-telemetry v7.0.0 (*)
          │       │   │   └── libdd-trace-stats v7.0.0 (*)
          │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
          │       │   ├── libdd-trace-stats v7.0.0 (*)
          │       │   └── libdd-trace-utils v10.1.0 (*)
          │       ├── libdd-common-ffi v41.0.0
          │       │   ├── datadog-sidecar v0.0.1 (*)
          │       │   └── libdd-crashtracker-ffi v41.0.0 (*)
          │       ├── (build) libdd-crashtracker v2.0.0 (*)
          │       ├── libdd-crashtracker-ffi v41.0.0 (*)
          │       ├── libdd-data-pipeline v8.0.0 (*)
          │       ├── libdd-dogstatsd-client v5.0.0 (*)
          │       ├── libdd-ffe v1.0.0 (*)
          │       ├── libdd-ipc v0.1.0 (*)
          │       ├── libdd-remote-config v3.0.0 (*)
          │       ├── libdd-shared-runtime v3.0.0 (*)
          │       ├── libdd-telemetry v7.0.0 (*)
          │       ├── libdd-trace-obfuscation v6.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── libdd-trace-utils v10.1.0 (*)
          ├── hyper-util v0.1.17
          │   ├── httpmock v0.8.0-alpha.1 (*)
          │   ├── hyper-rustls v0.27.7 (*)
          │   ├── libdd-common v5.2.0 (*)
          │   └── libdd-remote-config v3.0.0 (*)
          ├── libdd-common v5.2.0 (*)
          ├── libdd-common-ffi v41.0.0 (*)
          ├── libdd-remote-config v3.0.0 (*)
          └── libdd-trace-utils v10.1.0 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:233:1
    │
233 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v1.0.0
          └── datadog-sidecar v0.0.1

advisories FAILED, bans ok, sources ok

📦 libdd-common - 3 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               └── libdd-common v5.2.0
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 └── libdd-common v5.2.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.2.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.2.0

advisories FAILED, bans ok, sources ok

📦 libdd-crashtracker - 2 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:61:1
   │
61 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── (dev) libdd-crashtracker v2.0.0
                     └── (dev) libdd-ddsketch v1.1.1
                         └── libdd-telemetry v7.0.0
                             └── libdd-crashtracker v2.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:99:1
   │
99 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0258
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
   ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
     If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
     
     Low severity.
     
     Patched in v0.4.16.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
   ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
   ├ h2 v0.4.6
     └── hyper v1.6.0
         ├── httpmock v0.8.0-alpha.1
         │   └── (dev) libdd-telemetry v7.0.0
         │       └── libdd-crashtracker v2.0.0
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v5.2.0
         │       ├── libdd-capabilities-impl v4.0.0
         │       │   ├── libdd-crashtracker v2.0.0 (*)
         │       │   ├── libdd-shared-runtime v3.0.0
         │       │   │   └── libdd-telemetry v7.0.0 (*)
         │       │   └── (dev) libdd-telemetry v7.0.0 (*)
         │       ├── (build) libdd-crashtracker v2.0.0 (*)
         │       ├── libdd-shared-runtime v3.0.0 (*)
         │       └── libdd-telemetry v7.0.0 (*)
         ├── hyper-util v0.1.17
         │   ├── httpmock v0.8.0-alpha.1 (*)
         │   ├── hyper-rustls v0.27.7 (*)
         │   └── libdd-common v5.2.0 (*)
         └── libdd-common v5.2.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-data-pipeline - 2 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:77:1
   │
77 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   ├── libdd-data-pipeline v8.0.0
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v7.0.0
                     │   │   │   │       └── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-trace-stats v7.0.0 (*)
                     │   │   └── libdd-trace-utils v10.1.0
                     │   │       ├── libdd-data-pipeline v8.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v6.0.0
                     │   │       │   └── libdd-trace-stats v7.0.0 (*)
                     │   │       ├── libdd-trace-stats v7.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   ├── libdd-dogstatsd-client v5.0.0 (*)
                     │   ├── libdd-shared-runtime v3.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   ├── libdd-trace-obfuscation v6.0.0 (*)
                     │   ├── libdd-trace-stats v7.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-data-pipeline v8.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v7.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.1
                     │   ├── libdd-data-pipeline v8.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-trace-obfuscation v6.0.0 (*)
                     ├── (dev) libdd-trace-stats v7.0.0 (*)
                     └── (dev) libdd-trace-utils v10.1.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:117:1
    │
117 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      └── hyper v1.6.0
          ├── httpmock v0.8.0-alpha.1
          │   ├── (dev) libdd-data-pipeline v8.0.0
          │   ├── (dev) libdd-telemetry v7.0.0
          │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │   │   └── libdd-trace-stats v7.0.0
          │   │       └── libdd-data-pipeline v8.0.0 (*)
          │   ├── (dev) libdd-trace-stats v7.0.0 (*)
          │   └── libdd-trace-utils v10.1.0
          │       ├── libdd-data-pipeline v8.0.0 (*)
          │       ├── libdd-trace-obfuscation v6.0.0
          │       │   └── libdd-trace-stats v7.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── (dev) libdd-trace-utils v10.1.0 (*)
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v5.2.0
          │       ├── libdd-capabilities-impl v4.0.0
          │       │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   ├── libdd-shared-runtime v3.0.0
          │       │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   │   ├── libdd-dogstatsd-client v5.0.0
          │       │   │   │   ├── libdd-data-pipeline v8.0.0 (*)
          │       │   │   │   └── libdd-trace-stats v7.0.0 (*)
          │       │   │   ├── libdd-telemetry v7.0.0 (*)
          │       │   │   └── libdd-trace-stats v7.0.0 (*)
          │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
          │       │   ├── libdd-trace-stats v7.0.0 (*)
          │       │   └── libdd-trace-utils v10.1.0 (*)
          │       ├── libdd-data-pipeline v8.0.0 (*)
          │       ├── libdd-dogstatsd-client v5.0.0 (*)
          │       ├── libdd-shared-runtime v3.0.0 (*)
          │       ├── libdd-telemetry v7.0.0 (*)
          │       ├── libdd-trace-obfuscation v6.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── libdd-trace-utils v10.1.0 (*)
          ├── hyper-util v0.1.17
          │   ├── httpmock v0.8.0-alpha.1 (*)
          │   ├── hyper-rustls v0.27.7 (*)
          │   └── libdd-common v5.2.0 (*)
          ├── libdd-common v5.2.0 (*)
          └── libdd-trace-utils v10.1.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-ddsketch - 1 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:19:1
   │
19 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     └── (dev) libdd-ddsketch v1.1.1

advisories FAILED, bans ok, sources ok

📦 libdd-library-config - ✅ No issues

📦 libdd-profiling - 5 error(s)

Show output 
error[unsound]: `Bitmap::try_from(&[u8])` can create invalid values
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:14:1
   │
14 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2025-0167
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0167
   ├ The `TryFrom<&[u8]>` implementation for `Bitmap<SIZE>` copies the input bytes
     into an uninitialized backing store and calls `assume_init()` without
     validating that the bytes form a valid value of the backing store type. For
     `SIZE = 1` the backing store is a `bool`, so any input byte other than `0x00`
     or `0x01` produces an invalid value, which is immediate undefined behavior.
     
     The `AsMut<[u8]>` implementation has the same problem, as it allows safe code
     to write invalid bit patterns into the backing store through the returned slice.
     
     No fixed version is available, as the crate is unmaintained; its GitHub
     repository was archived by the owner on 2026-05-03.
   ├ Announcement: https://github.com/bodil/bitmaps/issues/35
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[unmaintained]: bitmaps is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:14:1
   │
14 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2026-0247
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0247
   ├ The bitmaps crate is unmaintained; all versions are affected. The GitHub
     repository was archived by the owner on 2026-05-03.
     
     Recommended alternatives:
     
     * [fixedbitset](https://crates.io/crates/fixedbitset)
     * [bitvec](https://crates.io/crates/bitvec)
   ├ Announcement: https://github.com/bodil/bitmaps
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:48:1
   │
48 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               └── (dev) libdd-profiling v1.0.0
     │                   └── (dev) libdd-profiling v1.0.0 (*)
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 ├── libdd-common v5.2.0
                 │   └── libdd-profiling v1.0.0 (*)
                 └── libdd-profiling v1.0.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:78:1
   │
78 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             ├── libdd-common v5.2.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:78:1
   │
78 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             ├── libdd-common v5.2.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-trace-normalization - 1 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:19:1
   │
19 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     └── (dev) libdd-trace-normalization v3.0.1

advisories FAILED, bans ok, sources ok

📦 libdd-trace-stats - 2 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:68:1
   │
68 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   └── libdd-trace-stats v7.0.0
                     │   │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-trace-stats v7.0.0 (*)
                     │   │   └── libdd-trace-utils v10.1.0
                     │   │       ├── libdd-trace-obfuscation v6.0.0
                     │   │       │   └── libdd-trace-stats v7.0.0 (*)
                     │   │       ├── libdd-trace-stats v7.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
                     │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   └── libdd-trace-stats v7.0.0 (*)
                     │   ├── libdd-shared-runtime v3.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   ├── libdd-trace-obfuscation v6.0.0 (*)
                     │   ├── libdd-trace-stats v7.0.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v7.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.1
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-trace-obfuscation v6.0.0 (*)
                     ├── (dev) libdd-trace-stats v7.0.0 (*)
                     └── (dev) libdd-trace-utils v10.1.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:106:1
    │
106 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      └── hyper v1.6.0
          ├── httpmock v0.8.0-alpha.1
          │   ├── (dev) libdd-telemetry v7.0.0
          │   │   └── libdd-trace-stats v7.0.0
          │   ├── (dev) libdd-trace-stats v7.0.0 (*)
          │   └── libdd-trace-utils v10.1.0
          │       ├── libdd-trace-obfuscation v6.0.0
          │       │   └── libdd-trace-stats v7.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── (dev) libdd-trace-utils v10.1.0 (*)
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v5.2.0
          │       ├── libdd-capabilities-impl v4.0.0
          │       │   ├── libdd-shared-runtime v3.0.0
          │       │   │   ├── libdd-telemetry v7.0.0 (*)
          │       │   │   └── libdd-trace-stats v7.0.0 (*)
          │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
          │       │   ├── libdd-trace-stats v7.0.0 (*)
          │       │   └── libdd-trace-utils v10.1.0 (*)
          │       ├── libdd-dogstatsd-client v5.0.0
          │       │   └── libdd-trace-stats v7.0.0 (*)
          │       ├── libdd-shared-runtime v3.0.0 (*)
          │       ├── libdd-telemetry v7.0.0 (*)
          │       ├── libdd-trace-obfuscation v6.0.0 (*)
          │       ├── libdd-trace-stats v7.0.0 (*)
          │       └── libdd-trace-utils v10.1.0 (*)
          ├── hyper-util v0.1.17
          │   ├── httpmock v0.8.0-alpha.1 (*)
          │   ├── hyper-rustls v0.27.7 (*)
          │   └── libdd-common v5.2.0 (*)
          ├── libdd-common v5.2.0 (*)
          └── libdd-trace-utils v10.1.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-trace-utils - 2 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:63:1
   │
63 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   └── libdd-trace-utils v10.1.0
                     │   │       └── (dev) libdd-trace-utils v10.1.0 (*)
                     │   └── libdd-trace-utils v10.1.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.1
                     │   └── libdd-trace-utils v10.1.0 (*)
                     └── (dev) libdd-trace-utils v10.1.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:97:1
   │
97 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0258
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
   ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
     If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
     
     Low severity.
     
     Patched in v0.4.16.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
   ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
   ├ h2 v0.4.6
     └── hyper v1.6.0
         ├── httpmock v0.8.0-alpha.1
         │   └── libdd-trace-utils v10.1.0
         │       └── (dev) libdd-trace-utils v10.1.0 (*)
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v5.2.0
         │       ├── libdd-capabilities-impl v4.0.0
         │       │   └── libdd-trace-utils v10.1.0 (*)
         │       └── libdd-trace-utils v10.1.0 (*)
         ├── hyper-util v0.1.17
         │   ├── httpmock v0.8.0-alpha.1 (*)
         │   ├── hyper-rustls v0.27.7 (*)
         │   └── libdd-common v5.2.0 (*)
         ├── libdd-common v5.2.0 (*)
         └── libdd-trace-utils v10.1.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-08-20 16:55:58 UTC | Commit: d271a73 | dependency-check job results

ekump added 2 commits August 20, 2026 11:59
@ekump
Merge remote-tracking branch 'origin/main' into oscarld/solve-cargo-d…
e149d64 
…eny-on-libdd-data-pipeline

# Conflicts:
#	Cargo.lock
#	libdd-common/Cargo.toml
@ekump
Merge remote-tracking branch 'origin/main' into oscarld/solve-cargo-d…
68f79be 
…eny-on-libdd-data-pipeline
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@chatgpt-codex-connector chatgpt-codex-connector[bot] chatgpt-codex-connector[bot] left review comments
@brettlangdon brettlangdon brettlangdon approved these changes
@mabdinur mabdinur mabdinur approved these changes
@hoolioh hoolioh hoolioh approved these changes

Assignees

No one assigned

Labels

common crashtracker data-pipeline mini-agent sidecar

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@Eldolfin @brettlangdon @mabdinur @hoolioh @ekump