# DF-4777 — VERDICT

**REPRODUCED — kernel-heap out-of-bounds READ (info leak) to an
operator-group userspace process, deterministic 3/3 runs with recognizable
kernel-memory content, and the one-file fix is validated live on a rebuilt
kernel (over-read eliminated, device still functional).**

## Root cause

`sys/dev/misc/ipmi/ipmi_kcs.c` — `kcs_polled_request()`:

- reply collection loop (ipmi_kcs.c:411-431): `i` counts **every** data
  byte the BMC streams in KCS READ state. Storage is bounded
  (`if (i < req->ir_replybuflen)` at :420) but the count is not.
- `req->ir_replylen = i;` (ipmi_kcs.c:432) records the BMC-controlled total.

`sys/dev/misc/ipmi/ipmi.c` — `ipmi_ioctl()` IPMICTL_RECEIVE_MSG(_TRUNC)
(ipmi.c:448-468): `len = kreq->ir_replylen + 1` is trusted;
`len = min(recv->msg.data_len, len)` (user `data_len` up to 65535) then
`copyout(kreq->ir_reply, recv->msg.data + 1, len - 1)` reads `ir_replylen`
bytes out of a buffer of exactly `IPMI_MAX_RX = 1024` bytes
(`ipmi_alloc_request`, ipmi.c:534-546; reply length for ioctl requests is
always IPMI_MAX_RX, ipmi.c:401-403; `sys/sys/ipmi.h:35`). A BMC that streams
> ~2 KB of data bytes before returning to IDLE (trivial for a hostile BMC;
each READ byte is one port read) turns every RECEIVE ioctl into a kernel
heap disclosure of up to 64 KB past the `kmalloc` chunk. Repeatable per
request; length chosen by the BMC; readout by any process in group
`operator` (`/dev/ipmi0` 0660 root:operator, ipmi.c:831-832).
The SMIC backend has the identical defect (ipmi_smic.c:341) — same fix.

Attack class: CWE-125 (OOB read) chained from a hostile-management-
controller trust boundary (the kernel must not trust BMC-reported lengths).
Adjacent-kernel-memory disclosure (CWE-909 family) is the impact.

## How it was reproduced (transport-substituted, sink fully live)

The stock QEMU `ipmi-bmc-sim` caps responses at MAX_IPMI_MSG_SIZE=255
(QEMU hw/ipmi/ipmi_kcs.c `ipmi_kcs_handle_rsp` truncates oversized BMC
replies), so the *transport half* (a BMC streaming 16000 data bytes) cannot
be produced by the built-in sim. The verification therefore reproduces
exactly the end state a hostile BMC produces — `ir_replylen = 16000 > 1024`
on a completed request — with a root-loaded harness module (`bumpko.c`,
hot-patches ipmi0's `dev_ops.d_ioctl`, sets `ir_replylen` under IPMI_LOCK on
the head of the calling fd's completed queue, then calls the unmodified
original ioctl). **Everything from the RECEIVE ioctl onward — the length
math and the `copyout` at ipmi.c:448-468 — runs in the stock kernel, and
the readout process is unprivileged** (maxx, uid 1001, groups
maxx+operator).

Heap grooming (30 same-size-class M_IPMI chunks filled with a recognizable
pattern; the oldest 20 freed so the victim reuses a chunk *below* live
patterned chunks) makes the disclosed neighbor content identifiable.

Observed, 3/3 independent runs (run.log, run.2.log, run.3.log):

```
RECEIVE ok: msg.data_len = 16001 (compcode + 16000 reply bytes)
nonzero in [0,1024):     1          <- the BMC's real (2-byte-ish) reply
nonzero in [1024,16000): 7136-7144  (first at 0x042e)
marker fragments beyond the victim BMC data: 424
```

Leaked content at the first foreign offset (leak_sample.txt):

- `0xfffff8008dcfc8c8`-style kernel heap pointers (slab-zone linkage of the
  adjacent chunk) at ir_reply[1070+] = 70 bytes past the victim's 2048-class
  kmalloc chunk end — exactly matching the allocation geometry
  (`ir_reply` = chunk+80+900; chunk = 2048 bytes);
- 424 occurrences of the "DF4777MARK-" pattern from the *live* neighboring
  kernel allocations (~940 nonzero bytes per 2048-byte stride in the block
  census = 900 pattern bytes + allocator metadata).

Control (run.control.log): arming a *legal* reply length (200 < 1024)
yields zero bytes beyond the real reply — the over-read manifests only when
the transport-reported length exceeds the buffer, i.e. exactly the hostile
BMC condition.

Honest scope: the primitive is an info **leak**, not a write. Escalation to
uid=0 is not reachable from this bug alone; the disclosed slab-adjacent
contents (kernel pointers, neighboring allocation data) would feed a
separate exploitation chain, and on this guest (no KASLR) the pointer
disclosure is directly usable for defeating any future randomization of the
leaked region's occupants.

## Fix validation (mandatory quality bar — done)

`fix.diff` (3 hunks, `git apply`-clean on the guest's /usr/src):

1. `ipmi_kcs.c`: clamp `i` to `req->ir_replybuflen` before storing
   `ir_replylen` (fixes the real hostile-BMC path at collection time);
2. `ipmi_smic.c`: identical clamp for the twin SMIC backend;
3. `ipmi.c`: defense-in-depth — clamp `len` to `ir_replybuflen + 1` in the
   RECEIVE path (fixes any other producer of an inflated ir_replylen).

Build: `make nativekernel KERNCONF=X86_64_GENERIC && make installkernel`
(BUILD-OK, fix_build.log), reboot into
`DragonFly 6.5-DEVELOPMENT #1: Wed Sep 23 15:29:40 UTC 2026`.

Same PoC, same arming (ir_replylen=16000), 2/2 runs (fix_run.log and
confirmation):

```
RECEIVE ok: msg.data_len = 1025 (compcode + 1024 reply bytes)
nonzero in [1024,1024):  0
marker fragments beyond the victim BMC data: 0
```

The over-read is gone (in the module-assisted flow the ipmi.c sink clamp is
the defense that fires; the kcs clamp covers the real BMC path), and normal
IPMI traffic over the KCS sim continues to work (the SEND/RECEIVE round
trips in the PoC itself prove driver functionality on the patched kernel).

## kernel_refs
- sys/dev/misc/ipmi/ipmi_kcs.c:411-431 (unbounded BMC byte count)
- sys/dev/misc/ipmi/ipmi_kcs.c:432 (ir_replylen = i, unclamped)
- sys/dev/misc/ipmi/ipmi.c:448-468 (trusting consumer + copyout OOB read)
- sys/dev/misc/ipmi/ipmi.c:534-546 (fixed 1024-byte ir_reply allocation)
- sys/dev/misc/ipmi/ipmi.c:831-832 (operator-group device node)
- sys/dev/misc/ipmi/ipmi_smic.c:341 (twin)
- sys/sys/ipmi.h:35 (IPMI_MAX_RX 1024)

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.