CVE-2026-45681: OpenTelemetry eBPF Instrumentation CPU-mismatch Fallback Uses 256-byte Buffer Vulnerability

MODERATE
Advisory Identifier: GHSA-r6c9-g6q5-qrf9
CVSS 5.9
CWE-125 CWE-130
Published
Advisory Summary

CVE-2026-45681 is a MODERATE (CVSS 5.9) cpu-mismatch fallback uses 256-byte buffer vulnerability (CWE-125: Out-of-bounds Read) affecting OpenTelemetry eBPF Instrumentation libraries in the Go ecosystem. The issue involves cpu-mismatch fallback uses 256-byte buffer with 8kb size. Remediation is available by upgrading affected packages to version 0.9.0.

CVE-2026-45681 at a Glance

CVE Identifier CVE-2026-45681
GHSA Identifier GHSA-r6c9-g6q5-qrf9
Severity MODERATE
CVSS v3.1 Base Score 5.9
CWE Classification CWE-125: Out-of-bounds Read
Affected Product OpenTelemetry eBPF Instrumentation
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 5.9

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-45681

To remediate this vulnerability, upgrade all affected OpenTelemetry eBPF Instrumentation dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

go.opentelemetry.io/obi fixed: 0.9.0
Upgrade go.opentelemetry.io/obi to 0.9.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for go.opentelemetry.io/obi

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-45681, inspect your project dependencies for OpenTelemetry eBPF Instrumentation:

inspect dependencies for go.opentelemetry.io/obi

Analyze the terminal output to locate any version of OpenTelemetry eBPF Instrumentation in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.9.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-125: Out-of-bounds Read, where the product reads data past the end, or before the beginning, of the intended buffer. In OpenTelemetry eBPF Instrumentation, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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: ```c // 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: ```bash 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: ```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` 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.

CVE-2026-45681 Affected OpenTelemetry eBPF Instrumentation Versions

1 component(s)
Fixed Versions:
0.9.0
Product / Package Ecosystem Affected Versions Fixed Version
go.opentelemetry.io/obi
Go
< 0.9.0
0.9.0

References

Frequently Asked Questions

What is CVE-2026-45681?
CVE-2026-45681 is a security vulnerability in OpenTelemetry eBPF Instrumentation involving CPU-mismatch fallback uses 256-byte buffer with 8KB size under CWE-125: Out-of-bounds Read.
Which OpenTelemetry eBPF Instrumentation versions are affected?
Affected versions include releases prior to 0.9.0 across affected packages: go.opentelemetry.io/obi.
What version fixes CVE-2026-45681?
Upgrading to 0.9.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is go.opentelemetry.io/obi affected?
Yes, go.opentelemetry.io/obi is affected in releases prior to 0.9.0. Upgrade your dependency to 0.9.0 or later.
What is the CVSS score of CVE-2026-45681?
CVE-2026-45681 has a CVSS v3.1 base score of 5.9 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N.
What CWE is associated with CVE-2026-45681?
CVE-2026-45681 is classified under CWE-125: Out-of-bounds Read (The product reads data past the end, or before the beginning, of the intended buffer.).
How can I check Go dependencies for CVE-2026-45681?
Run the dependency tree command: 'inspect dependencies for go.opentelemetry.io/obi'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-r6c9-g6q5-qrf9",
  "modified" : "2026-06-09T10:58:36Z",
  "published" : "2026-05-18T20:11:20Z",
  "aliases" : [ "CVE-2026-45681" ],
  "summary" : "OpenTelemetry eBPF Instrumentation: CPU-mismatch fallback uses 256-byte buffer with 8KB size",
  "details" : "### Summary\n\nThe 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.\n\n### Details\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/http_buf_size.h#L4-L7\n\n`k_kprobes_http2_buf_size` is defined as 256 bytes, the size of the fallback buffer.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/msg_buffer.h#L12-L36\n\nIntroduces 8KB per-CPU buffer and 256-byte `fallback_buf` in `msg_buffer_t`, creating a size mismatch for fallback use.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/k_tracer.c#L370-L394\n\nOn CPU mismatch, `fallback_buf `is used but size is still set to `m_buf->real_size` (up to 8KB) and passed downstream.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/protocol_http.h#L412-L441\n\n`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.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/tpinjector/tpinjector.c#L192-L206\n\n`real_size `is set up to 8192 bytes and stored with `cpu_id`; `fallback_buf `only contains 256 bytes.\n\n### PoC\n\nLocal 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.\n\nTo reproduce the validated behavior locally:\n\n1. create a struct that models `fallback_buf[256]` and `real_size`\n2. populate only the 256-byte fallback buffer\n3. simulate the CPU mismatch path by using the fallback buffer as the source pointer while preserving a much larger `real_size`\n4. perform a read of `real_size` bytes from that 256-byte backing store under ASan\n\nAn equivalent reproducer is:\n\n```c\n// save as /tmp/poc_msgbuf_oob.c\n#include <stdint.h>\n#include <stdio.h>\n#include <string.h>\n\nstruct msg_buffer {\n  unsigned char fallback_buf[256];\n  uint16_t pos;\n  uint16_t real_size;\n  uint32_t cpu_id;\n};\n\nint main(void) {\n  struct msg_buffer m = {0};\n  unsigned char sink[8192];\n\n  memset(m.fallback_buf, 'A', sizeof(m.fallback_buf));\n  m.real_size = 4096;\n\n  memcpy(sink, m.fallback_buf, m.real_size);\n  printf(\"copied %u bytes from a 256-byte fallback buffer\\n\", m.real_size);\n  return 0;\n}\n```\n\nCompile and run with ASan:\n\n```bash\ncc -fsanitize=address -O1 -g -o /tmp/poc_msgbuf_oob /tmp/poc_msgbuf_oob.c\nASAN_OPTIONS=abort_on_error=1 /tmp/poc_msgbuf_oob\n```\n\nExpected result:\n\n```text\nAddressSanitizer: heap-buffer-overflow or stack-buffer-overflow\n```\n\nThat 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.\n\n### Impact\n\nThis 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "go.opentelemetry.io/obi"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.9.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-r6c9-g6q5-qrf9"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-45681"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.9.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-125", "CWE-130" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-18T20:11:20Z",
    "nvd_published_at" : "2026-06-02T16:16:42Z"
  }
}