| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| github.com/inspektor-gadget/inspektor-gadget | ≥ 0.27.0, < 0.53.1 | 0.53.1 |
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.
To be assessed — Availability impact, no confidentiality or integrity impact.
All versions of Inspektor Gadget that support uprobe-based gadgets (trace_malloc, trace_open, trace_ssl, trace_grpc, etc.).
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:
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.
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.
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.
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.これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン/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).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:
readStringFromBytes call uses quadratic string concatenationIn 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 ""
}
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.