CVE-2026-45681: OpenTelemetry eBPF Instrumentation: CPU-mismatch fallback uses 256-byte buffer with 8KB size

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/httpbufsize.h#L4-L7

kkprobeshttp2bufsize is defined as 256 bytes, the size of the fallback buffer.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/msgbuffer.h#L12-L36

Introduces 8KB per-CPU buffer and 256-byte fallbackbuf in msgbuffert, creating a size mismatch for fallback use.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/ktracer.c#L370-L394

On CPU mismatch, fallbackbuf is used but size is still set to mbuf->realsize (up to 8KB) and passed downstream.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/protocolhttp.h#L412-L441

byteslen (from mbuf->realsize) is used to read payload data from ubuf; if ubuf 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

realsize is set up to 8192 bytes and stored with cpuid; fallbackbuf 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 fallbackbuf[256] and realsize 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 realsize 4. perform a read of realsize bytes from that 256-byte backing store under ASan

An equivalent reproducer is:

c // save as /tmp/pocmsgbufoob.c #include <stdint.h> #include <stdio.h> #include <string.h>

struct msgbuffer { unsigned char fallbackbuf[256]; uint16t pos; uint16t realsize; uint32t cpuid; };

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

memset(m.fallbackbuf, 'A', sizeof(m.fallbackbuf)); m.realsize = 4096;

memcpy(sink, m.fallbackbuf, m.realsize); printf("copied %u bytes from a 256-byte fallback buffer\n", m.realsize); return 0; }

Compile and run with ASan:

bash cc -fsanitize=address -O1 -g -o /tmp/pocmsgbufoob /tmp/pocmsgbufoob.c ASANOPTIONS=abortonerror=1 /tmp/pocmsgbufoob

Expected result:

text 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 sockmsg 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.