Summary

kue_attach() allocates sc->sc_mcfilters using KUE_MCFILTCNT(sc), but the device descriptor that KUE_MCFILTCNT reads has not been fetched yet at that point (it is only read later in kue_attach_post()). The softc is zero-initialised by newbus, so KUE_MCFILTCNT(sc) is 0, kmalloc(0) returns the sentinel ZERO_LENGTH_PTR = (void *)-8 (kern_slaballoc.c:193, 890), and the NULL check at line 490 passes because (void *)-8 != NULL. Later, a malicious (or even legitimate) USB device reports kue_mcastfilt >= 1 in GET_ETHER_DESCRIPTOR; on the next multicast reconfiguration (which happens automatically when the interface is brought up due to default IPv6 multicast), kue_setmulti() memcpy()s ETHER_ADDR_LEN bytes into &ZERO_LENGTH_PTR[0] = 0xFFFF...FFF8 on x86-64, an unmapped kernel address, causing a page fault and immediate kernel panic. The write target is the fixed ZERO_LENGTH_PTR sentinel, which the attacker cannot redirect, so this is a reliable DoS with no path to code execution.

Root cause

Walkthrough:

1. kue_attach() (if_kue.c:468) runs first; at line 488 it calls sc->sc_mcfilters = kmalloc(KUE_MCFILTCNT(sc) * ETHER_ADDR_LEN, M_USBDEV, M_WAITOK).

2. KUE_MCFILTCNT is defined in if_kuereg.h:69 as (UGETW((x)->sc_desc.kue_mcastfilt) & 0x7FFF) — i.e., it reads a uint16 out of the device descriptor. At this instant sc_desc is whatever newbus left: device softcs are zero-allocated with M_ZERO at subr_bus.c:1953-1954, so kue_mcastfilt = {0, 0}, KUE_MCFILTCNT(sc) = 0, and 0 * ETHER_ADDR_LEN = 0.

3. DragonFlyBSD's slab allocator returns the sentinel ZERO_LENGTH_PTR for kmalloc(0) (kern_slaballoc.c:888-891, with ZERO_LENGTH_PTR = (void *)-8 at line 193).

4. The subsequent if (sc->sc_mcfilters == NULL) test at if_kue.c:490 does NOT catch this because (void *)-8 is non-NULL.

5. kue_attach() then calls uether_ifattach() (line 501), which queues ue_attach_post_task; the post task calls kue_attach_post() (if_kue.c:422-444), which loads firmware, resets the chip, and only THEN reads the descriptor at lines 439-440 via kue_ctl(KUE_CMD_GET_ETHER_DESCRIPTOR, &sc->sc_desc, sizeof(sc->sc_desc)). A malicious device supplies kue_mcastfilt encoding any value N >= 1, so KUE_MCFILTCNT(sc) now returns N. The sc_mcfilters buffer is NEVER reallocated — it is still the 0-byte ZERO_LENGTH_PTR.

6. When kue_setmulti() (if_kue.c:354-398) runs in response to SIOCADDMULTI (queued from uether_ioctl() at usb_ethernet.c:497-504), the loop at lines 373-387 iterates i from 0; for each AF_LINK multicast entry with i < KUE_MCFILTCNT(sc) it executes memcpy(KUE_MCFILT(sc, i), ..., ETHER_ADDR_LEN) (lines 383-385).

7. KUE_MCFILT(sc, i) expands (if_kuereg.h:70-71) to (char *)&sc->sc_mcfilters[i * ETHER_ADDR_LEN], which for i = 0 is (char *)ZERO_LENGTH_PTR + 0 = (char *)0xFFFFFFFFFFFFFFF8 on x86-64. The first such memcpy writes 6 bytes starting at an unmapped kernel address and the CPU traps with a page fault, immediately panic'ing the kernel.

Because every iteration writes to the fixed sentinel (which is always unmapped), there is no path by which the attacker can land the write on a mapped, attacker-influenced region — this caps impact at denial of service.

Note that real KL5KUSB101B hardware reportedly advertises a 128-entry filter (comment at if_kue.c:51), so this bug does not require a malicious device; any genuine kue(4) NIC whose firmware reports a non-zero multicast filter count will panic the host the moment its interface is brought up with IPv6 enabled.

Threat model & preconditions

• Attacker position: Anyone who can attach a USB device to the target — physical plug-in, USB-C charging station, compromised USB hub, or a BadUSB / Rubber-Ducky-class gadget. No kernel privileges and no authentication are needed. The device must merely present one of the ~30 supported (VID, PID) pairs (if_kue.c:104-139, all trivially spoofable via a USB gadget), accept the KUE_CMD_SEND_SCAN firmware-download requests (return success / stall — kue_load_fw ignores some failures and kue_attach_post ignores the rest at line 430-433), and respond to KUE_CMD_GET_ETHER_DESCRIPTOR with kue_mcastfilt >= 1.
• Privileges gained or impact: Complete system crash / reboot (A:H). No confidentiality or integrity impact because the write address is the unredirectable ZERO_LENGTH_PTR sentinel in unmapped KVA.
• Required config or capabilities: Default kernel with kue. Local ueN interface brought up (often automatic via NetworkManager / dhcpcd / default IPv6).
• Reachability: Trigger sequence: 1. Plug in malicious kue-identifying USB device. 2. kue driver attaches → kue_attach() (allocates 0-byte buffer) → kue_attach_post() (reads malicious descriptor). 3. Interface is brought up (ifconfig ueN up — commonly done automatically). 4. IPv6 stack installs the solicited-node and all-nodes multicast addresses (33:33:00:00:00:01, 33:33:ff:<last3>) → fires SIOCADDMULTI → kue_setmulti() → OOB write → page fault → kernel panic.

Proof of PoC

Two-part PoC.

(A) Malicious USB device side — implemented as a Linux USB gadget (Pi Zero W / BeagleBone / any configfs-gadget target) or a Facedancer board.

• Device descriptor: bcdDevice != 0x0202 (so kue_load_fw doesn't early-return at if_kue.c:305-306) and one of the kue_devs[] VID/PID tuples, e.g. idVendor=0x04cf (KLSI), idProduct=0x0001 (DUH3E10BT).
• Control endpoint handlers: 1. ACK or accept the three KUE_CMD_SEND_SCAN (0xFF) OUT requests carrying kue_code_seg / kue_fix_seg / kue_trig_seg (size and content do not matter — kue_ctl just needs to return success). 2. Respond to the vendor IN request bmRequestType=0xC0 bRequest=0x00 (KUE_CMD_GET_ETHER_DESCRIPTOR) with a 16-byte kue_ether_desc whose bytes [12..13] (kue_mcastfilt) are little-endian >= 1, e.g. 0x20 0x00 (N=32); the remaining bytes can be anything.

(B) Host trigger — after the device enumerates and the kue driver attaches:

sudo ifconfig ue0 up
# or just wait for dhcpcd / NetworkManager to do it.

On a DragonFlyBSD host with IPv6 enabled (the default), the in-kernel IPv6 code will immediately add 33:33:00:00:00:01 and 33:33:ff:xx:xx:xx to the interface, triggering SIOCADDMULTI and thus kue_setmulti(). The first memcpy into &ZERO_LENGTH_PTR[0] panics the kernel.

Build & run

# gadget descriptor Python (pyusb/facedancer) runs on the attacker device
python3 kue_evil_gadget.py

# host side: nothing to compile, just bring up the interface
sudo ifconfig ue0 up

Expected output

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xFFFFFFFFFFFFFFF8
cpuid = 0
instruction pointer     = 0x<PC inside memcpy>
kue_setmulti(...) at if_kue.c:383
...
panic: from-rights-free

Impact

Reliable kernel panic from a USB plug-in + interface up. The write is to the unredirectable ZERO_LENGTH_PTR sentinel so no code-execution primitive. Medium severity per "physical access + automatic trigger" + "reliable DoS". Affects both malicious and legitimate kue NICs.

Recommended fix

Move the sc_mcfilters allocation from kue_attach() (where KUE_MCFILTCNT is 0 because the descriptor has not been read) into kue_attach_post() (where it has just been read), and guard the kfree() in kue_detach() because DragonFlyBSD's kfree(NULL) panics (kern_slaballoc.c:1406-1407) while kfree(ZERO_LENGTH_PTR) is a no-op — so removing the early kmalloc(0) leaves sc_mcfilters == NULL on the uether_ifattach-failure path, which must not be freed.

--- a/sys/bus/u4b/net/if_kue.c
+++ b/sys/bus/u4b/net/if_kue.c
@@ -435,6 +435,17 @@ kue_attach_post(struct usb_ether *ue)
    /* read ethernet descriptor */
    kue_ctl(sc, KUE_CTL_READ, KUE_CMD_GET_ETHER_DESCRIPTOR,
        0, &sc->sc_desc, sizeof(sc->sc_desc));
+
+   /*
+    * Allocate the multicast filter buffer now that the device has
+    * reported its multicast filter capacity in the descriptor above.
+    * This MUST happen here, not in kue_attach(): at kue_attach() time
+    * the descriptor has not been fetched yet and the zero-initialised
+    * softc would yield KUE_MCFILTCNT(sc)==0, producing a zero-length
+    * allocation that kue_setmulti() would later write past.
+    */
+   sc->sc_mcfilters = kmalloc(KUE_MCFILTCNT(sc) * ETHER_ADDR_LEN,
+       M_USBDEV, M_WAITOK);

    /* copy in ethernet address */
    memcpy(ue->ue_eaddr, sc->sc_desc.kue_macaddr, sizeof(ue->ue_eaddr));
 }
@@ -485,13 +496,6 @@ kue_attach(device_t dev)
        goto detach;
    }

-   sc->sc_mcfilters = kmalloc(KUE_MCFILTCNT(sc) * ETHER_ADDR_LEN,
-       M_USBDEV, M_WAITOK);
-   if (sc->sc_mcfilters == NULL) {
-       device_printf(dev, "failed allocating USB memory\n");
-       goto detach;
-   }
-
    ue->ue_sc = sc;
    ue->ue_dev = dev;
    ue->ue_udev = uaa->device;
@@ -514,12 +518,15 @@ static int
 kue_detach(device_t dev)
 {
    struct kue_softc *sc = device_get_softc(dev);
    struct usb_ether *ue = &sc->sc_ue;

    usbd_transfer_unsetup(sc->sc_xfer, KUE_N_TRANSFER);
    uether_ifdetach(ue);
+
+   /* kfree(NULL) panics on DragonFlyBSD, so guard the free for the
+    * uether_ifattach-failure path where kue_attach_post never ran. */
+   if (sc->sc_mcfilters != NULL)
+       kfree(sc->sc_mcfilters, M_USBDEV);
    lockuninit(&sc->sc_lock);
-   kfree(sc->sc_mcfilters, M_USBDEV);

    return (0);
 }

A defense-in-depth follow-up would also cap KUE_MCFILTCNT (e.g. min(UGETW(...) & 0x7FFF, 128)) so a malicious device cannot force a ~192 KB allocation, and would widen the i * ETHER_ADDR_LEN argument to kue_ctl() / USETW(wLength) so it does not silently truncate when i * 6 > 65535.

References

• sys/bus/u4b/net/if_kue.c:488-493 — the premature allocation
• sys/bus/u4b/net/if_kue.c:439-440 — descriptor read in kue_attach_post
• sys/bus/u4b/net/if_kue.c:381-385 — memcpy(KUE_MCFILT(sc, i), ..., ETHER_ADDR_LEN)
• sys/bus/u4b/net/if_kuereg.h:69-71 — KUE_MCFILTCNT / KUE_MCFILT macros
• sys/kern/kern_slaballoc.c:193, 888-891 — ZERO_LENGTH_PTR and kmalloc(0)
• sys/kern/subr_bus.c:1953-1954 — newbus M_ZERO softc allocation
• CWE-131 Incorrect Calculation of Buffer Size
• CWE-787 Out-of-bounds Write

Timeline

• 2026-07-14 Discovered during automated audit.