OpenTelemetry eBPF Instrumentation provides eBPF instrumentation based on the OpenTelemetry standard. From version 0.7.0 to before version 0.9.0, OBI's log enricher mishandles writev buffers by reading only the first iovec entry but using the total iov_iter.count as the copy length. When log injection is enabled, a crafted multi-segment writev call can make OBI read and overwrite memory beyond the first segment. This issue has been patched in version 0.9.0.

Affected: Go: go.opentelemetry.io/obi

### Summary

OBI's log enricher mishandles `writev` buffers by reading only the first `iovec` entry but using the total `iov_iter.count` as the copy length. When log injection is enabled, a crafted multi-segment `writev` call can make OBI read and overwrite memory beyond the first segment.

### Details

In [bpf/logenricher/logenricher.c#L50](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/360521f411213566a3b557a1f0c093e6cd68a4de/bpf/logenricher/logenricher.c#L50), `__fill_iov` resolves only one `struct iovec`, specifically `iov_ctx.iov[0]` for `ITER_IOVEC`. The returned `iov` therefore describes only the first write segment.

However, `__write` later uses `const size_t count = BPF_CORE_READ(from, count);`, which is the total byte count across all segments in the iterator. That total is stored in `e->len` and used in `bpf_probe_read_user(e->log, e->len, iov.iov_base)` and `bpf_probe_write_user(iov.iov_base, zero, to_write)`.

If `count` exceeds `iov.iov_len`, OBI reads and then zeroes memory past the end of the first segment. In practice, this can corrupt adjacent application buffers, leak memory into log events, and in some layouts destabilize the instrumented process.

### PoC

Local testing with a minimal ASan harness reproduced the same out-of-bounds read/write condition as the vulnerable `writev` path.

Use a vulnerable build with the log enricher enabled.

```bash git checkout v0.7.0 make build ```

Create a program that performs a two-element…

alloy-1.19.2-1.1 on GA media