OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, the custom CappedConcurrentHashMap introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory. This issue has been patched in version 0.9.0.
Affected: Go: go.opentelemetry.io/obi
### Summary
The custom `CappedConcurrentHashMap` introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory.
### Details
The vulnerable implementation is in [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11). New keys are appended to a `ConcurrentLinkedQueue`, and eviction only runs inside `put()` when `map.size() > capacity`.
The `remove()` method removes the key from the `ConcurrentHashMap` but leaves the key in the queue. Because `evictIfNeeded()` only checks `map.size() > capacity`, the queue can grow forever in workloads that insert and remove keys while keeping the live map below the cap.
This pattern is reachable from [pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66), where `cleanupConnectionBufMapping` remov…
alloy-1.17.0-1.1 on GA media
Security update for alloy