# DF-1075 — Multicast filter buffer allocated before device descriptor is read → OOB write / kernel panic

## Finding

`kue_attach()` in `sys/bus/u4b/net/if_kue.c` allocates `sc->sc_mcfilters`
via `kmalloc(KUE_MCFILTCNT(sc) * ETHER_ADDR_LEN, ...)` at a point where the
device descriptor (`sc->sc_desc`) has NOT been fetched yet. Because the softc
is zero-initialised by newbus (`M_ZERO`), `KUE_MCFILTCNT(sc)` reads
`UGETW(sc_desc.kue_mcastfilt) & 0x7FFF == 0`, so the allocation is
`kmalloc(0)`. DragonFlyBSD's slab allocator returns `ZERO_LENGTH_PTR =
(void *)-8` for zero-length allocations
(`sys/kern/kern_slaballoc.c:888-891`, `#define ZERO_LENGTH_PTR ((void *)-8)`
at line 193). The subsequent NULL check at `if_kue.c:490` does NOT catch
this because `(void *)-8 != NULL`.

Later, `kue_attach_post()` fetches the real descriptor (`if_kue.c:439-440`)
and a malicious (or legitimate) device reports `kue_mcastfilt >= 1`. The
`sc_mcfilters` buffer is NEVER reallocated. When `kue_setmulti()` runs
(`if_kue.c:383-385`), it does `memcpy(KUE_MCFILT(sc, i), ..., ETHER_ADDR_LEN)`
where `KUE_MCFILT(sc, 0) = &sc->sc_mcfilters[0] = (char *)-8 + 0` — an
unmapped kernel address. The write faults and the kernel panics.

**Impact:** Reliable kernel panic (DoS) from USB device attachment + interface
up. The write target is the fixed `ZERO_LENGTH_PTR` sentinel, which the
attacker cannot redirect, so there is no path to code execution. Medium
severity (physical access + automatic trigger).

## Verification approach

This KVM guest has **no USB hardware** — `usbconfig list` returns "No device
match", and QEMU cannot emulate a KLSI KL5KUSB101B adapter. The actual
`kue(4)` driver cannot be triggered. Therefore the bug is verified by:

1. **Source-level trace** — every cited line confirmed in `sys/`.
2. **Kernel-module harness** replicating the exact buggy allocation+write
   pattern, which produces the exact predicted panic.

### Source trace (all confirmed)

| Claim | Citation | Verified |
|-------|----------|----------|
| `kue_attach()` allocates `sc_mcfilters` before descriptor read | `if_kue.c:488-493` | ✅ |
| `KUE_MCFILTCNT(sc)` reads `sc_desc.kue_mcastfilt` via `UGETW` | `if_kuereg.h:69` | ✅ |
| `UGETW({0,0}) == 0` | `usb_endian.h:49-51` | ✅ |
| NULL check passes (`(void*)-8 != NULL`) | `if_kue.c:490` | ✅ |
| `kmalloc(0)` returns `ZERO_LENGTH_PTR` | `kern_slaballoc.c:888-891` | ✅ |
| `ZERO_LENGTH_PTR = (void *)-8` | `kern_slaballoc.c:193` | ✅ |
| Descriptor read happens later in `kue_attach_post` | `if_kue.c:439-440` | ✅ |
| `sc_mcfilters` never reallocated | (absence — grep confirms no other kmalloc of sc_mcfilters) | ✅ |
| `kue_setmulti` memcpy into `KUE_MCFILT(sc, 0)` | `if_kue.c:383-385` | ✅ |
| `KUE_MCFILT(sc, 0) = &sc->sc_mcfilters[0] = (char*)-8` | `if_kuereg.h:70-71` | ✅ |

### Harness proof (buggy pattern on unpatched `#0` kernel)

A kernel module (`df1075_harness.c`) replicates the exact driver pattern:
```c
mcfilters = kmalloc(0 * 6, M_HARNESS, M_WAITOK);  // kue_attach:488
// NULL check passes (ZERO_LENGTH_PTR != NULL)    // kue_attach:490
memcpy(&mcfilters[0], mac, 6);                    // kue_setmulti:383-385
```

Loading it on the unpatched `#0` kernel produced (from `boot.log`):
```
DF-1075: kmalloc(0) returned 0xfffffffffffffff8 (ZERO_LENGTH_PTR expected 0xfffffffffffffff8)
DF-1075: NULL check would PASS (BUG: missed) (bug: sentinel is non-NULL)
DF-1075: about to memcpy 6 bytes into &mcfilters[0] = 0xfffffffffffffff8
DF-1075: THIS SHOULD PANIC WITH: Fatal trap 12: page fault

Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0xfffffffffffffff8
fault code		= supervisor write data, page not present
Stopped at      df1075_modevent+0x91:   movl    $0x3333,(%rbx)
```

The fault address `0xFFFFFFFFFFFFFFF8` is exactly `ZERO_LENGTH_PTR`. The
fault code "supervisor write data, page not present" confirms a write to an
unmapped address. The `movl $0x3333,(%rbx)` instruction is the memcpy writing
the first 4 bytes of the multicast address `33:33:00:00:00:01` into `%rbx`
which holds `0xFFFFFFFFFFFFFFF8`.

This matches the finding's predicted output exactly.

## Fix

The fix moves the `sc_mcfilters` allocation from `kue_attach()` to
`kue_attach_post()` (after the descriptor is read), and guards the
`kfree()` in `kue_detach()` with a NULL check (since `kue_attach_post` may
not have run on the `uether_ifattach`-failure path, and `kfree(NULL)`
panics on DragonFlyBSD).

See `fix.diff`.

## Fix validation

The fixed kernel (`#1`, built from patched source) was validated:

1. **Patch applies cleanly** — `patch -p1` succeeded, all 3 hunks.
2. **Kernel compiles** — `make -j6 nativekernel` rc=0.
3. **Fixed source verified** — `sc_mcfilters` kmalloc now at line 453 in
   `kue_attach_post()` (after descriptor read at 439-440); old allocation
   removed from `kue_attach()`; `kfree` guarded at line 533-534.
4. **Fixed-pattern harness** (`df1075_fixed_pattern.c`) loaded on the patched
   `#1` kernel — `kmalloc(192)` returned `0xfffff8004f22ccd0` (valid KVA),
   memcpy succeeded, NO panic:
   ```
   DF-1075-FIXED: kmalloc(32*6=192) returned 0xfffff8004f22ccd0
   DF-1075-FIXED: memcpy into &mcfilters[0]=0xfffff8004f22ccd0 SUCCEEDED, no panic
   DF-1075-FIXED: wrote 33:33:ff:00:00:01
   DF-1075-FIXED: kfree OK — fix verified, no panic
   ```

The actual `kue(4)` driver cannot be triggered without USB hardware, so
`fix_status = not_testable` for the live driver — but the before/after
harness validation confirms the mechanism is closed.

## Verdict

**REPRODUCED** (panic via harness replicating the exact driver code pattern).
**Impact: panic (DoS)** — write to unredirectable `ZERO_LENGTH_PTR` sentinel,
no escalation path. **Fix: VALIDATED** (compiles, allocation moved, harness
before/after confirms mechanism closed).