Inspektor Gadget Uprobe gadgets: unprivileged container's ld.so.cache causes high CPU utilization and container startup DoS

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

Inspektor Gadget is a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF. From 0.27.0 until 0.53.1, the uprobe library resolver can allow an unprivileged container to consume excessive CPU and block other containers from starting by supplying a crafted /etc/ld.so.cache file while an uprobe-based gadget is active. The parser in pkg/uprobetracer/ldcache_parser.go trusts EntryCount enough to perform excessive iteration, computes cache1Len with overflowing uint32 arithmetic, and repeatedly calls readStringFromBytes in pkg/uprobetracer/bytes.go, where byte-by-byte immutable string concatenation produces quadratic work. While this processing occurs, pkg/container-hook holds the fanotify container-start pause, allowing a crafted cache to delay startup for roughly a minute, prevent Docker from starting other containers, and degrade monitoring. Processing caches from already-running containers can still consume CPU but does not hold the new-container startup pause, and the advisory establishes no confidentiality or integrity impact. This issue is fixed in version 0.53.1.

Source published

15 Sep 2026 17:02:00 UTC

Source modified

16 Sep 2026 15:09:02 UTC

Saved here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Inspektor Gadget is a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF. From 0.27.0 until 0.53.1, the uprobe library resolver can allow an unprivileged container to consume excessive CPU and block other containers from starting by supplying a crafted /etc/ld.so.cache file while an uprobe-based gadget is active. The parser in pkg/uprobetracer/ldcache_parser.go trusts EntryCount enough to perform excessive iteration, computes cache1Len with overflowing uint32 arithmetic, and repeatedly calls readStringFromBytes in pkg/uprobetracer/bytes.go, where byte-by-byte immutable string concatenation produces quadratic work. While this processing occurs, pkg/container-hook holds the fanotify container-start pause, allowing a crafted cache to delay startup for roughly a minute, prevent Docker from starting other containers, and degrade monitoring. Processing caches from already-running containers can still consume CPU but does not hold the new-container startup pause, and the advisory establishes no confidentiality or integrity impact. This issue is fixed in version 0.53.1.

Source published

Sep 15, 2026, 5:02:00 PM (timezone not stated)

Source modified

Sep 16, 2026, 3:09:02 PM (timezone not stated)

Saved here

11 Nov 2026 13:58:17 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 4.0 · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Inspektor Gadget is a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF. From 0.27.0 until 0.53.1, the uprobe library resolver can allow an unprivileged container to consume excessive CPU and block other containers from starting by supplying a crafted /etc/ld.so.cache file while an uprobe-based gadget is active. The parser in pkg/uprobetracer/ldcache_parser.go trusts EntryCount enough to perform excessive iteration, computes cache1Len with overflowing uint32 arithmetic, and repeatedly calls readStringFromBytes in pkg/uprobetracer/bytes.go, where byte-by-byte immutable string concatenation produces quadratic work. While this processing occurs, pkg/container-hook holds the fanotify container-start pause, allowing a crafted cache to delay startup for roughly a minute, prevent Docker from starting other containers, and degrade monitoring. Processing caches from already-running containers can still consume CPU but does not hold the new-container startup pause, and the advisory establishes no confidentiality or integrity impact. This issue is fixed in version 0.53.1.

Source published

15 Sep 2026 18:17:22 UTC

Source modified

30 Sep 2026 17:43:24 UTC

Saved here

25 Oct 2026 13:17:22 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 4.0 · [email protected] · Secondary · 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

## Summary An unprivileged container can block all other containers from starting on the same host by placing a crafted `/etc/ld.so.cache` file in its filesystem. When Inspektor Gadget attaches any uprobe-based gadget, it parses this file in the container startup path. A malicious cache causes ~53 seconds of CPU burn, during which Docker cannot start any other container. No special capabilities are required. ## Severity To be assessed — Availability impact, no confidentiality or integrity impact. ## Affected Versions All versions of Inspektor Gadget that support uprobe-based gadgets (trace_malloc, trace_open, trace_ssl, trace_grpc, etc.). ## Description When Inspektor Gadget attaches uprobe-based gadgets to containers, it resolves library paths by parsing the container's `/etc/ld.so.cache` file (`pkg/uprobetracer/ldcache_parser.go`). This file is fully controlled by the container. The parser has three vulnerabilities: 1. **Quadratic string building** (`pkg/uprobetracer/bytes.go:36-44`): The `readStringFromBytes` function concatenates one byte at a time (`res += string(data[i])`), which is O(n²) in Go due to string immutability. With a 16MB cache file containing large regions without null terminators, this causes massive CPU and memory churn. 2. **Insufficient entry count validation** (`pkg/uprobetracer/ldcache_parser.go:120`): The `EntryCount` field is read directly from the untrusted file. While a per-entry bounds check prevents out-of-bounds access, the loop still iterates up to `(fileSize - headerSize) / entrySize ≈ 700,000` times, calling `readStringFromBytes` on each iteration. 3. **Integer overflow in format detection** (`pkg/uprobetracer/ldcache_parser.go:174`): The `cache1Len` computation uses uint32 arithmetic (`ldCache1Size + cache1.EntryCount*ldCache1EntrySize`). With a crafted `EntryCount`, this overflows and produces a small value, causing the parser to misidentify the cache format. Combined, these cause ~53 seconds of CPU burn per container attachment when a crafted 16MB `/etc/ld.so.cache` is present. ## Impact - **Container runtime DoS**: IG uses fanotify hooks (`pkg/container-hook`) to pause container startup until uprobe attachment completes. While IG is blocked processing the malicious cache, this pause is held, and Docker serializes container starts — meaning no other container can start on the host until IG finishes. This effectively causes a denial of service on the entire container runtime, not just on IG itself. - **Container startup delay**: When any uprobe-based gadget is running (trace_malloc, trace_ssl, etc.), starting a container with a crafted ld.so.cache delays startup by ~1 minute. - **Monitoring degradation**: The IG daemon is blocked processing the malicious cache, potentially missing events from other containers. - **Amplification**: Multiple containers with crafted caches can be started simultaneously to amplify the effect. - **No special privileges required**: Any container can include a crafted `/etc/ld.so.cache` in its image, mount one via a volume, or overwrite it at runtime before IG starts a uprobe gadget. In this last case, IG inspects all already-running containers when the gadget starts — this still burns CPU but does not block other containers from starting (since the fanotify pause only applies to new container starts). ## Root Cause Analysis In `pkg/uprobetracer/ldcache_parser.go`, the function `readCacheFormat2` is called with the full file content: ```go for i := uint32(0); i < ldCache.EntryCount; i++ { entryOffset := ldEntriesOffset + i*ldCache2EntrySize if uint32(len(data)) <= entryOffset+ldCache2EntrySize { return nil // bounds check stops iteration } // ... reads entry ... key := readStringFromBytes(data, keyOffset) // O(n²) per call value := readStringFromBytes(data, valueOffset) // O(n²) per call } ``` The per-entry bounds check correctly prevents out-of-bounds access, but: - The loop iterates ~700K times (limited by file size, not EntryCount) - Each `readStringFromBytes` call uses quadratic string concatenation In `pkg/uprobetracer/bytes.go`: ```go func readStringFromBytes(data []byte, startPos uint32) string { res := "" for i := startPos; i < uint32(len(data)); i++ { if data[i] == 0 { return res } res += string(data[i]) // O(n²) — allocates new string each iteration } return "" } ``` ## Note on Slice Bounds Checks The code also performs slice accesses without proper bounds checks (e.g., `data[:len(cache2Header)]` when `data` may be shorter than 20 bytes, and `ldCacheFile[:len(cache1Header)]` when the file may be shorter than 11 bytes). In practice, a malicious container **cannot currently trigger a panic** from these missing checks. This is because Go's `io.ReadAll` (used to read the file) always returns slices with `cap >= 512` due to its initial buffer allocation (`make([]byte, 0, 512)` in Go's standard library). In Go, `s[:n]` only panics when `n > cap(s)`, not when `n > len(s)`. Since both header lengths (11 and 20) are well below 512, the slice expressions succeed — they simply read zero bytes beyond `len`, which don't match any valid header magic. However, this relies on an **undocumented implementation detail** of `io.ReadAll` which could change in future Go versions. The bounds checks are still necessary for correctness and defense in depth.

Source published

19 Aug 2026 19:16:35 UTC

Source modified

26 Aug 2026 01:21:31 UTC

Saved here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Publisher rating · MODERATE

Uprobe gadgets: unprivileged container's ld.so.cache causes high CPU utilization and container startup DoS in github.com/inspektor-gadget/inspektor-gadget

Source published

25 Aug 2026 19:43:10 UTC

Source modified

26 Aug 2026 01:21:31 UTC

Saved here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · OSV · upstream source license applies. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.