CVE-2026-45681

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\n", 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.

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.

A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.

CVE-2026-45681 has a CVSS score of 5.9 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.9.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-45681? CVE-2026-45681 is a medium-severity out-of-bounds read vulnerability in go.opentelemetry.io/obi (go), affecting versions < 0.9.0. It is fixed in 0.9.0. A read operation accesses a memory location beyond the intended buffer boundary.
2. How severe is CVE-2026-45681? CVE-2026-45681 has a CVSS score of 5.9 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of go.opentelemetry.io/obi are affected by CVE-2026-45681? go.opentelemetry.io/obi (go) versions < 0.9.0 is affected.
4. Is there a fix for CVE-2026-45681? Yes. CVE-2026-45681 is fixed in 0.9.0. Upgrade to this version or later.
5. Is CVE-2026-45681 exploitable, and should I be worried? Whether CVE-2026-45681 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45681 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45681? Upgrade go.opentelemetry.io/obi to 0.9.0 or later.