# DF-0600 — PoC: dup_sockaddr sa_len OOB read

Privileged local heap OOB read. `dup_sockaddr` trusts `sa->sa_len`
unconditionally; `smb_memdupin` allocates from user-supplied `ioc_svlen`.
A user who supplies `ioc_svlen=4` with a `sockaddr` whose first byte
(`sa_len`) is `200` causes `dup_sockaddr` to `bcopy` 200 bytes out of a
4-byte kernel heap allocation.

## Files

- `oob_read.c` — minimal reproducer (`SMBIOC_OPENSESSION` with mismatched
  `ioc_svlen` vs `sa_len`).
- (added by per-PoC verifier) `build.sh`, `run.sh`, `build.log`, `run.log`,
  `VERDICT.md`, `manifest.json`, `fix.diff`.

## Build & run

```
cc -I/usr/src/sys -I/usr/src/sys/netproto/smb -o oob_read oob_read.c
sudo ./oob_read
```

## Expected first outcome

`dup_sockaddr` will `bcopy` 200 bytes from the 4-byte `buf` → heap OOB read.
Either panics (if `buf` is at page boundary) or silently copies 196
adjacent bytes into `vcp->vc_paddr`. The silent-copy case is observable
only via the `CONNADDREQ` comparison oracle in subsequent `SMBIOC_LOOKUP`
calls.

## Notes for the per-PoC verifier

- The OOB read itself can panic the kernel if the source buffer is at the
  end of a slab page and the read crosses an unmapped page; otherwise it
  silently copies adjacent heap into `vc_paddr`.
- The indirect-comparison oracle (via `CONNADDREQ` in `smb_sm_lookupint`)
  provides a 1-bit (match/no-match) signal per attempt — a byte-by-byte
  brute-force of the leaked contents is possible with effort but requires
  heap-layout determinism.
- Verify the fix with `git apply findings/poc/DF-0600/fix.diff` (the
  `sa_len` validation before `dup_sockaddr` calls in `smb_vc_create`);
  after the fix the ioctl should return `EINVAL` cleanly without OOB read.