DF-5397 — urndis(4) attach-failure paths call urndis_detach() on a

never-attached usb_ether -> deterministic kernel panic (lockmgr NULL)

What

sys/bus/u4b/net/if_urndis.c — urndis_attach() failure paths (if_urndis.c:258-299: "No valid alternate setting found", "Unable to get hardware address", "Invalid address length", "Unable to set data filters") jump to:

detach:
    urndis_detach(dev);          /* if_urndis.c:309-311 */
    return (ENXIO);

ue->ue_lock, ue->ue_methods etc. are assigned only at if_urndis.c:290-294 — after every failure goto — and uether_ifattach() never ran. urndis_detach() calls uether_ifdetach(ue); on DragonFly every guard there is dead:

• usb_proc_drain() early-returns (zeroed up_lock) — safe;
• uether_getifp(ue) returns the address of the embedded ue->ue_arpcom.ac_if — never NULL — so if (ifp != NULL) passes;
• UE_LOCK(ue) → lockmgr(ue->ue_lock == NULL) → page fault VA 0.

Identical class to DF-5334 (cdce). An attacker-supplied USB device (evil RNDIS NIC / tethering dongle — precisely this driver's threat model) triggers it by making the attach fail once: e.g. malformed class-specific descriptors so usbd_transfer_setup() finds no usable alternate setting on the data interface (the exact gadget used here), or by failing/short-answering the RNDIS MAC query.

Reproduction (baseline, stock if_urndis.ko)

Malformed RNDIS gadget over usb-redir (RNDIS_MALFORMED=1 boot_rig_cold.sh, usbredir_rndis.py with malformed on):

urndis0: <vendor 0x0525 product 0xa4a2, class 2/0, rev 2.00/0.00, addr 2> on usbus0
urndis0: No valid alternate setting found
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
Stopped at      lockmgr_exclusive+0x5d: orl     (%r14),%esi

lockmgr_exclusive() at lockmgr_exclusive+0x5d
uether_ifdetach() at uether_ifdetach+0x2f
urndis_detach() at urndis_detach+0x2a
urndis_attach() at urndis_attach+0x11d
device_doattach() at device_doattach+0x3af
usb_probe_and_attach() at usb_probe_and_attach+0x176
uhub_explore() at uhub_explore+0x231
usb_bus_explore() at usb_bus_explore+0xd0
usb_process() at usb_process+0x76

(4 independent reproductions; crash dump taken via call dumpsys. A second variant — "Unable to get hardware address" when the RNDIS query response is rejected — panics at urndis_attach+0x13a with the same teardown, captured in run.serial-baseline-panic-usbdebug.log.)

Fix validation (patched if_urndis.ko, fix.diff)

fix.diff replaces the error-path urndis_detach(dev) with a teardown of only what was actually initialised (USB transfers + the softc lock). Same malformed device, patched module:

urndis0: <vendor 0x0525 product 0xa4a2, class 2/0, rev 2.00/0.00, addr 2> on usbus0
urndis0: No valid alternate setting found
device_probe_and_attach: urndis0 attach returned 6

Guest stays up (ssh alive, zero Fatal trap in dmesg.boot), attach retried cleanly, and the unpatched flow of DF-5396 (valid device) still attaches (ue0: MAC address: 02:00:de:ad:be:ef) — no regression.

Run it

1. guest: mv /boot/kernel/if_cdce.ko /root/ (cdce's VPI match on 0525:a4a2 would win probe priority and panic via its own DF-5334 bug first), kldload if_urndis
2. host: RNDIS_MALFORMED=1 sh boot_rig_cold.sh (device present at boot, malformed CS descriptors) — or toggle malformed on on the control port and replug.
3. baseline: panic (above); patched: clean ENXIO, guest survives.

Kernel references

• sys/bus/u4b/net/if_urndis.c:290-294 (ue fields assigned after all failure gotos), :309-311 (goto detach -> urndis_detach)
• sys/bus/u4b/net/usb_ethernet.c:268-314 (uether_ifdetach), :54-56 (URNDIS/UE lock macros), sys/bus/u4b/usb_process.c (drain guard)
• sibling finding DF-5334 (cdce, same class)

DF-5397 VERDICT

Status: reproduced (deterministic kernel panic / local-device DoS via attach-failure path). Fix: validated on the guest.

How reproduced

The malicious usbredir RNDIS device (usbredir_rndis.py from the DF-5396 pack, RNDIS_MALFORMED=1) presents CDC class-specific descriptors whose walked lengths are one byte too long each, so DF's config parse never finds the data interface and urndis_attach()\'s alternate-setting loop fails on every iteration -> "No valid alternate setting found" -> goto detach -> urndis_detach(dev) -> uether_ifdetach() over the never-initialised usb_ether -> lockmgr(NULL) -> Fatal trap 12, VA 0.

Four independent baseline reproductions (two descriptor-failure variants: alt-setting failure and MAC-query rejection), each with the DDB backtrace naming uether_ifdetach+0x2f <- urndis_detach+0x2a <- urndis_attach, and a crash dump via call dumpsys. Evidence: panic.txt, run.serial-baseline-panic-usbdebug.log (USB_DEBUG kernel, annotated), run.serial-baseline-panic2.log, run.serial-patched-clean.log.

Why not worse than a panic

The faulting pointer is NULL (ue_lock), so the primitive is a denial-of-service at attach time (device plug-in / boot with the evil gadget present). Because the panic happens with preemption state of the usb explore thread and a fully attacker-chosen timing window, it is also a reliability/UX kill: a boot-time evil device bricks the boot (serial DDB, ssh never starts). No memory-corruption primitive was identified in this path (the NULL is dereferenced, not written through).

Fix validation

fix.diff (tear down only usbd transfers + lock, never uether_ifdetach on the un-attached ue) applied on the guest, module rebuilt + installed:

• malformed device replug: urndis0: No valid alternate setting found + device_probe_and_attach: urndis0 attach returned 6, guest alive, zero Fatal traps.
• valid device (regression): full attach + DF-5396 differential ran on the same patched module build (ue0 up, RNDIS data path live).

Notes

• cdce (DF-5334) shares the bug and must be kept from probing first for this driver's PoC (VPI 0525:a4a2 beats urndis's class match).
• FreeBSD's urndis_attach has the same shape; whether FreeBSD's uether_ifdetach is equally unguarded was not verified in this run.

Kernel references

sys/bus/u4b/net/if_urndis.c:290-294, :309-311; sys/bus/u4b/net/usb_ethernet.c:268-314; DF-5334 (cdce sibling).

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.