OpenTelemetry eBPF Instrumentation: Memcached payload length overflow can crash OBI
Date: 2026-05
Affected: go/go.opentelemetry.io/obi
Attack vector: rce
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-45676
CVE-2026-45678
CVE-2026-45680
CVE-2026-45682
CVE-2026-45683
CVE-2026-45685
CVE-2026-45686
CWE: CWE-127
CWE-190
CWE-20
CWE-200
CWE-248
CWE-400
CWE-401
CWE-704
CWE-754
CWE-770
CWE-834
CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

### Summary A remotely reachable integer overflow in OBI's memcached text protocol parser can crash the OBI process and cause denial of service. When parsing memcached storage commands such as `set`, `add`, `replace`, `append`, `prepend`, or `cas`, OBI accepts extremely large `<bytes>` values and adds the payload delimiter length without checking for overflow. A crafted request with `<bytes>` set to `math.MaxInt` or `math.MaxInt-1` causes the computed payload length to wrap negative and triggers a runtime panic in `LargeBufferReader.Peek`. ### Details The issue is in the memcached request parser at `pkg/ebpf/common/memcached_detect_transform.go`. `memcachedCommandBytesField` parses the storage command `<bytes>` field with `strconv.Atoi` and only rejects negative values: ```go size, err := strconv.Atoi(string(fields[4])) if err != nil || size < 0 { return 0, false } ``` Because there is no upper bound check, values up to `math.MaxInt` are accepted. `memcachedConsumeStoragePayload` then computes the payload length by adding the trailing `\r\n` delimiter length: ```go payloadLen := bytesField + len(memcachedDelimBytes) payload, err := r.Peek(payloadLen) ``` If `bytesField` is `math.MaxInt` or `math.MaxInt-1`, this addition overflows the signed `int` and produces a negative `payloadLen`. That negative length is passed into `LargeBufferReader.Peek` in `pkg/internal/largebuf/large_buffer.go`. `Peek` checks whether `n > Remaining()` but does not reject negative values bef


Mitigations:

Architectural layers (MAESTRO):