https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:11:47 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-324314 EUVD-2026-324314 https://cve.radiocsirt.org/vuln/euvd-2026-324314 https://cve.radiocsirt.org/vuln/fkie_cve-2026-45680 <p>OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval. This issue has been patched in version 0.9.0.</p> <p>OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. Prior to version 0.9.0, OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval. This issue has been patched in version 0.9.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-45680 https://cve.radiocsirt.org/vuln/ghsa-89c6-vpcj-7vj4 <p><strong>Affected:</strong> Go: go.opentelemetry.io/obi</p> <p>### Summary</p> <p>OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval.</p> <p>### Details</p> <p>The vulnerable loop is in [pkg/export/prom/prom_bpf.go](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4a39d3b307968df4b54e89b8dee297e7d772ca29/pkg/export/prom/prom_bpf.go#L128-L144). During each metrics tick, OBI iterates through `probeMetrics` and then executes `for range metric.count`, invoking `BpfProbeLatency(...)` for each individual recorded hit.</p> <p>The count comes from [`calculateStats()`](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4a39d3b307968df4b54e89b8dee297e7d772ca29/pkg/export/prom/prom_bpf.go#L326-L335) in the same file, where `deltaCount := bp.runCount - bp.prevRunCount` is calculated and returned without any cap before the per-hit replay loop.</p> <p>If probe activity spikes between scrape intervals, `deltaCount` can be very large. The exporter then spends CPU time proportional to the number of probe hits rather than the number of metric series.</p> <p>### PoC</p> <p>Local testing with a small reproducer confirmed the replay-loop behavior and showed CPU scaling with the recorded hit count rather than the number of metric series.</p> <p>Use a vulnerable build and enable internal metrics export:</p> <p>```bash git checkout v0.0.0-rc.1+build make build export…</p> <p><strong>Affected:</strong> Go: go.opentelemetry.io/obi</p> <p>### Summary</p> <p>OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval.</p> <p>### Details</p> <p>The vulnerable loop is in [pkg/export/prom/prom_bpf.go](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4a39d3b307968df4b54e89b8dee297e7d772ca29/pkg/export/prom/prom_bpf.go#L128-L144). During each metrics tick, OBI iterates through `probeMetrics` and then executes `for range metric.count`, invoking `BpfProbeLatency(...)` for each individual recorded hit.</p> <p>The count comes from [`calculateStats()`](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4a39d3b307968df4b54e89b8dee297e7d772ca29/pkg/export/prom/prom_bpf.go#L326-L335) in the same file, where `deltaCount := bp.runCount - bp.prevRunCount` is calculated and returned without any cap before the per-hit replay loop.</p> <p>If probe activity spikes between scrape intervals, `deltaCount` can be very large. The exporter then spends CPU time proportional to the number of probe hits rather than the number of metric series.</p> <p>### PoC</p> <p>Local testing with a small reproducer confirmed the replay-loop behavior and showed CPU scaling with the recorded hit count rather than the number of metric series.</p> <p>Use a vulnerable build and enable internal metrics export:</p> <p>```bash git checkout v0.0.0-rc.1+build make build export…</p> https://cve.radiocsirt.org/vuln/ghsa-89c6-vpcj-7vj4 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11803-1 <p>alloy-1.19.2-1.1 on GA media</p> <p>alloy-1.19.2-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11803-1