PT-2026-41786 · Go · Go.Opentelemetry.Io/Obi

Published

2026-05-18

·

Updated

2026-05-18

·

CVE-2026-45681

CVSS v3.1

5.9

Medium

VectorAV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Summary

The per-CPU message-buffer fallback path uses a 256-byte backup buffer but preserves the original payload size, which can be up to 8KB. If a CPU mismatch occurs, OBI can read beyond the fallback buffer and leak adjacent memory into telemetry.

Details

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/http buf size.h#L4-L7
k kprobes http2 buf size is defined as 256 bytes, the size of the fallback buffer.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/msg buffer.h#L12-L36
Introduces 8KB per-CPU buffer and 256-byte fallback buf in msg buffer t, creating a size mismatch for fallback use.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/k tracer.c#L370-L394
On CPU mismatch, fallback buf is used but size is still set to m buf->real size (up to 8KB) and passed downstream.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/protocol http.h#L412-L441
bytes len (from m buf->real size) is used to read payload data from u buf; if u buf is the 256B fallback, this can over-read and leak memory into telemetry.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/tpinjector/tpinjector.c#L192-L206
real size is set up to 8192 bytes and stored with cpu id; fallback buf only contains 256 bytes.

PoC

Local testing with an AddressSanitizer user-space PoC reproduced the same class of size-mismatch over-read as the vulnerable fallback-buffer path. That result is sufficient to ground the advisory in a fresh local reproduction even though the exact end-to-end eBPF path still depends on host BPF capabilities.
To reproduce the validated behavior locally:
  1. create a struct that models fallback buf[256] and real size
  2. populate only the 256-byte fallback buffer
  3. simulate the CPU mismatch path by using the fallback buffer as the source pointer while preserving a much larger real size
  4. perform a read of real size bytes from that 256-byte backing store under ASan
An equivalent reproducer is:
// save as /tmp/poc msgbuf oob.c
#include <stdint.h>
#include <stdio.h>
#include <string.h>

struct msg buffer {
 unsigned char fallback buf[256];
 uint16 t pos;
 uint16 t real size;
 uint32 t cpu id;
};

int main(void) {
 struct msg buffer m = {0};
 unsigned char sink[8192];

 memset(m.fallback buf, 'A', sizeof(m.fallback buf));
 m.real size = 4096;

 memcpy(sink, m.fallback buf, m.real size);
 printf("copied %u bytes from a 256-byte fallback buffer
", m.real size);
 return 0;
}
Compile and run with ASan:
cc -fsanitize=address -O1 -g -o /tmp/poc msgbuf oob /tmp/poc msgbuf oob.c
ASAN OPTIONS=abort on error=1 /tmp/poc msgbuf oob
Expected result:
AddressSanitizer: heap-buffer-overflow or stack-buffer-overflow
That user-space PoC matches the size-mismatch condition in the vulnerable code path, even though the exact end-to-end eBPF runtime path still requires host BPF attach/load capability.

Impact

This is a confidentiality issue in the HTTP tracing path. The vulnerable read occurs in OBI's local fallback-buffer handling when context propagation is enabled, the tpinjector sock msg path is active, HTTP large-buffer capture is configured with a non-zero size, and a CPU mismatch occurs between producer and consumer contexts. Under those conditions, OBI can over-read from the fallback buffer and export unrelated memory through telemetry.

Fix

Out of bounds Read

Weakness Enumeration

CWE-125CWE-130

Related Identifiers

CVE-2026-45681
GHSA-R6C9-G6Q5-QRF9

Affected Products

Go.Opentelemetry.Io/Obi