DF-5384 — if_aue.c attach-failure DF-5334-class panic (goto-detach-on-unattached)

What

aue_attach() (sys/bus/u4b/net/if_aue.c) routes its device-controlled failure branch through aue_detach() on a usb_ether that was never attached — identical class to DF-5334 (if_cdce.c, proved on this guest):

• usbd_transfer_setup() fails (missing bulk/interrupt endpoints on an otherwise matching Pegasus device) → if_aue.c:689-691 goto detach → if_aue.c:707-708 aue_detach(dev).
• At that point ue->ue_lock, ue_dev, ue_udev, ue_methods, ue_tq are ALL still zero — they are assigned only at if_aue.c:694-698, after the failing call.
• aue_detach() (if_aue.c:719) calls uether_ifdetach(ue) (usb_ethernet.c:267-305): usb_proc_drain() is a no-op on the zeroed ue_tq; uether_getifp() returns the embedded arpcom ifnet (never NULL — the if (ifp != NULL) guard is dead code); then usb_ethernet.c:281 UE_LOCK(ue) = lockmgr(NULL, LK_EXCLUSIVE) → Fatal trap 12, fault VA 0x0.

The second failure branch (uether_ifattach() error, if_aue.c:700-704) has the same shape and additionally reaches ether_ifdetach() on a never-if_attach()ed ifnet → ifindex2ifnet[0] nulling + global ifnet list corruption (requires usb_proc_create() ENOMEM — not attacker-timed).

Threat model: attacker-supplied USB device (evil adapter / evil dock / VM attach) presenting any of the 68 VID:PID pairs in aue_devs[] (e.g. ADMtek Pegasus 0x077b:0x2226) at config 0 / iface 0 without the expected bulk-in/out + interrupt-in endpoints. Not remotely triggerable, not an unprivileged-local program — physical/VM USB access.

Reproduce (evidence class: KLD harness driving production code)

QEMU cannot emulate a Pegasus AN986. The harness aue_attach_poc.c replays aue_detach() verbatim (its two production calls, in order) on the exact state aue_attach()'s failure branch produces, using the production usbd_transfer_unsetup() and uether_ifdetach() (exported by uether.ko). The only non-production code is the static aue_attach/aue_detach frame itself (they are static in if_aue.c and only reachable via goto detach with a physical device present).

# build (in guest, source pack synced to /root/df5384)
cd /root/df5384 && make -m /usr/src/share/mk

# run (auto-loads STOCK /boot/kernel/uether.ko as dependency)
kldload -v ./aue_poc.ko
# expected: 3 marker lines, then
#   Fatal trap 12: page fault while in kernel mode
#   fault virtual address = 0x0
#   Stopped at lockmgr_exclusive+0x5d: orl (%r14),%esi
#   (guest dead in DDB)

Fix validation

fix.diff (git-apply-able against clean sys/): (a) class-wide guard in uether_ifdetach() — early return when ue->ue_lock == NULL (same fix already validated for DF-5334); (b) aue_attach() routes both pre-attach failure branches to a local detach_usb: label doing only usbd_transfer_unsetup() + lockuninit() (fixes the branch-2 ether_ifdetach-on-unattached corruption too).

Applied to the guest's /usr/src, both modules rebuilt -Werror clean, patched uether.ko installed: identical harness run prints aue_poc: SURVIVED uether_ifdetach(), KLDLOAD_RC=0, dmesg | grep -c 'Fatal trap' = 0, clean kldunload, patched if_aue.ko driver loads/unloads clean. See run.log vs panic.txt.

Files

• aue_attach_poc.c + Makefile — the harness
• build.log — harness build (full, -Werror)
• fix_uether_build.log / fix_if_aue_build.log — patched module builds
• panic.txt — baseline serial record (stock modules)
• run.log — patched run (survival proof)
• env.txt — guest uname, dmesg tail, kldstat
• fix.diff — the fix (never applied to the audit tree)
• VERDICT.md, manifest.json, verdict.json

DF-5384 VERDICT — REPRODUCED (panic), fixed

Finding. aue_attach() (sys/bus/u4b/net/if_aue.c) has the DF-5334 "goto-detach-on-unattached" pattern: the usbd_transfer_setup() failure branch (if_aue.c:689-691) and the uether_ifattach() failure branch (if_aue.c:700-704) both jump to detach: (if_aue.c:707-708) and call the full aue_detach(), which calls uether_ifdetach(&sc->sc_ue) (if_aue.c:719) on a usb_ether that was never attached.

Why it faults. On the transfer-setup failure path, every ue field that uether_ifdetach() needs is still zero because they are assigned only at if_aue.c:694-698 — after the failing call:

• usb_proc_drain(&ue->ue_tq) (usb_ethernet.c:273) returns immediately (up->up_lock == NULL, usb_process.c:406-410) — no fault, no initialization.
• ifp = uether_getifp(ue) (usb_ethernet.c:276) returns &ue->ue_arpcom.ac_if — never NULL, so the if (ifp != NULL) guard at :278 is dead code (same as DF-5334).
• UE_LOCK(ue) (usb_ethernet.c:281, macro at :61) is lockmgr(ue->ue_lock /* NULL */, LK_EXCLUSIVE) → read at VA 0x0 → Fatal trap 12.

The second branch (uether_ifattach error) leaves ue_lock valid but the ifnet never if_attach()ed; uether_ifdetach() proceeds to ether_ifdetach() (usb_ethernet.c:294) → if_detach() on if_index 0 → nulls ifindex2ifnet[0] (lo0) and TAILQ_REMOVEs a never-inserted ifnet from the global ifnet list (sys/net/if.c:966/982) — latent list corruption pre-empted by a NULL-write fault. That branch needs usb_proc_create() to fail (ENOMEM), so it is not attacker-timed; the transfer-setup branch is fully device-controlled: any USB device exposing one of the 68 aue_devs[] VID:PID pairs (e.g. ADMtek Pegasus 0x077b:0x2226) at config 0 / iface 0 while omitting the bulk-IN/OUT + interrupt-IN endpoints makes usbd_transfer_setup() fail (USB_ERR_NO_ENDPOINT) at plug-in.

Verification (evidence class: KLD harness driving production code — QEMU cannot emulate a Pegasus AN986; aue_attach/aue_detach are static and reachable only with hardware):

• The harness (aue_attach_poc.c) constructs the exact post-failure state (zeroed struct aue_softc + lockinit(&sc->sc_lock) per if_aue.c:683 — the only initialisation before the failing call) and replays aue_detach() verbatim: the production usbd_transfer_unsetup() then the production uether_ifdetach().
• Baseline (pristine with-src guest, stock /boot/kernel/uether.ko auto-loaded by MODULE_DEPEND): the three markers print, then Fatal trap 12: page fault while in kernel mode, fault virtual address = 0x0, current process = 987 (kldload), Stopped at lockmgr_exclusive+0x5d: orl (%r14),%esi — guest dead at DDB. Record: panic.txt. 1/1 run (deterministic NULL deref; DF-5334 proved the same sink 3/3 in-situ).
• Patched (fix.diff applied to guest /usr/src; uether.ko + if_aue.ko rebuilt -Werror clean; patched uether.ko into /boot/kernel): identical harness run prints aue_poc: SURVIVED uether_ifdetach() (the guard's early return), KLDLOAD_RC=0, dmesg | grep -c 'Fatal trap' = 0, kldunload clean, and the patched if_aue.ko driver module loads/unloads clean. Record: run.log, fix_uether_build.log, fix_if_aue_build.log.

Impact. Plug-time kernel NULL dereference (panic/DoS) from a malicious USB device — same severity tier and threat model as DF-5334 (Medium, physical/VM USB access). NOT memory corruption with attacker-controlled data: the fault address is fixed VA 0, the only "dereference" is the lockmgr read of the lock word at NULL. No user→root route. The latent branch-2 second stage (ifindex/ifnetlist corruption) is likewise plug-time corruption of fixed addresses — DoS.

Why this is a separate finding from DF-5334. DF-5334 was filed against if_cdce.c; its persisted fix (uether_ifdetach guard) was applied in-guest for validation only and then reverted — the tree still carries the unguarded uether_ifdetach, and every uether driver's attach-failure path is an independent instance. This finding covers the if_aue.c instance (root cause identical, trigger device-controlled the same way).

Fix. fix.diff: (a) uether_ifdetach() early-returns when ue->ue_lock == NULL (class-wide, matches the DF-5334 validated fix); (b) aue_attach() routes both pre-attach failures to detach_usb: doing only usbd_transfer_unsetup() + lockuninit() — (b) is required for the branch-2 ether_ifdetach-on-unattached corruption, which (a) alone does not stop. Validated in-guest (baseline panic gone, modules -Werror clean, driver loads).

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.