GHSA-VJHX-2CQW-3Q6Q

Vulnerability from github – Published: 2026-08-19 19:16 – Updated: 2026-08-19 19:16
VLAI
Summary
Uprobe gadgets: unprivileged container's ld.so.cache causes high CPU utilization and container startup DoS
Details

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:

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:

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.

Severity
6.9 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/inspektor-gadget/inspektor-gadget"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.27.0"
            },
            {
              "fixed": "0.53.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-19T19:16:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAn unprivileged container can block all other containers from starting on the\nsame host by placing a crafted `/etc/ld.so.cache` file in its filesystem. When\nInspektor Gadget attaches any uprobe-based gadget, it parses this file in the\ncontainer startup path. A malicious cache causes ~53 seconds of CPU burn,\nduring which Docker cannot start any other container. No special capabilities\nare required.\n\n## Severity\n\nTo be assessed \u2014 Availability impact, no confidentiality or integrity impact.\n\n## Affected Versions\n\nAll versions of Inspektor Gadget that support uprobe-based gadgets (trace_malloc, trace_open, trace_ssl, trace_grpc, etc.).\n\n## Description\n\nWhen Inspektor Gadget attaches uprobe-based gadgets to containers, it resolves library paths by parsing the container\u0027s `/etc/ld.so.cache` file (`pkg/uprobetracer/ldcache_parser.go`). This file is fully controlled by the container.\n\nThe parser has three vulnerabilities:\n\n1. **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\u00b2) in Go due to string immutability. With a 16MB cache file containing large regions without null terminators, this causes massive CPU and memory churn.\n\n2. **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 \u2248 700,000` times, calling `readStringFromBytes` on each iteration.\n\n3. **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.\n\nCombined, these cause ~53 seconds of CPU burn per container attachment when a crafted 16MB `/etc/ld.so.cache` is present.\n\n## Impact\n\n- **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 \u2014 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.\n- **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.\n- **Monitoring degradation**: The IG daemon is blocked processing the malicious cache, potentially missing events from other containers.\n- **Amplification**: Multiple containers with crafted caches can be started simultaneously to amplify the effect.\n- **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 \u2014 this still burns CPU but does not block other containers from starting (since the fanotify pause only applies to new container starts).\n\n## Root Cause Analysis\n\nIn `pkg/uprobetracer/ldcache_parser.go`, the function `readCacheFormat2` is called with the full file content:\n\n```go\nfor i := uint32(0); i \u003c ldCache.EntryCount; i++ {\n    entryOffset := ldEntriesOffset + i*ldCache2EntrySize\n    if uint32(len(data)) \u003c= entryOffset+ldCache2EntrySize {\n        return nil  // bounds check stops iteration\n    }\n    // ... reads entry ...\n    key := readStringFromBytes(data, keyOffset)    // O(n\u00b2) per call\n    value := readStringFromBytes(data, valueOffset) // O(n\u00b2) per call\n}\n```\n\nThe per-entry bounds check correctly prevents out-of-bounds access, but:\n- The loop iterates ~700K times (limited by file size, not EntryCount)\n- Each `readStringFromBytes` call uses quadratic string concatenation\n\nIn `pkg/uprobetracer/bytes.go`:\n\n```go\nfunc readStringFromBytes(data []byte, startPos uint32) string {\n    res := \"\"\n    for i := startPos; i \u003c uint32(len(data)); i++ {\n        if data[i] == 0 {\n            return res\n        }\n        res += string(data[i])  // O(n\u00b2) \u2014 allocates new string each iteration\n    }\n    return \"\"\n}\n```\n\n## Note on Slice Bounds Checks\n\nThe code also performs slice accesses without proper bounds checks (e.g.,\n`data[:len(cache2Header)]` when `data` may be shorter than 20 bytes, and\n`ldCacheFile[:len(cache1Header)]` when the file may be shorter than 11 bytes).\n\nIn practice, a malicious container **cannot currently trigger a panic** from these\nmissing checks. This is because Go\u0027s `io.ReadAll` (used to read the file) always\nreturns slices with `cap \u003e= 512` due to its initial buffer allocation\n(`make([]byte, 0, 512)` in Go\u0027s standard library). In Go, `s[:n]` only panics\nwhen `n \u003e cap(s)`, not when `n \u003e len(s)`. Since both header lengths (11 and 20)\nare well below 512, the slice expressions succeed \u2014 they simply read zero bytes\nbeyond `len`, which don\u0027t match any valid header magic.\n\nHowever, this relies on an **undocumented implementation detail** of `io.ReadAll`\nwhich could change in future Go versions. The bounds checks are still necessary\nfor correctness and defense in depth.",
  "id": "GHSA-vjhx-2cqw-3q6q",
  "modified": "2026-08-19T19:16:35Z",
  "published": "2026-08-19T19:16:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/inspektor-gadget/inspektor-gadget/security/advisories/GHSA-vjhx-2cqw-3q6q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/inspektor-gadget/inspektor-gadget"
    },
    {
      "type": "WEB",
      "url": "https://github.com/inspektor-gadget/inspektor-gadget/releases/tag/v0.53.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Uprobe gadgets: unprivileged container\u0027s ld.so.cache causes high CPU utilization and container startup DoS"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.