DF-5396 — urndis(4) bulk RX: 2-byte kernel heap overflow via RNDIS

rm_datalen (device-controlled) up to MCLBYTES copied after m_adj(ETHER_ALIGN)

What

sys/bus/u4b/net/if_urndis.c — urndis_bulk_read_callback(). The RX sanity chain accepts msg.rm_datalen up to and including MCLBYTES (2048) — if_urndis.c:859:

} else if (msg.rm_datalen > (uint32_t)MCLBYTES) {   /* rejects only > 2048 */
        ...
} else if (msg.rm_datalen > (uint32_t)(MHLEN - ETHER_ALIGN)) {
        m = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR);   /* 2048-byte cluster */
...
if (m != NULL) {
        m_adj(m, ETHER_ALIGN);                      /* m_data = cluster + 2 */
        usbd_copy_out(pc, ..., m->m_data, msg.rm_datalen);  /* up to 2048 */

After m_adj(m, ETHER_ALIGN) only MCLBYTES - ETHER_ALIGN (2046) bytes are writable from m->m_data, but the copy uses the unchecked rm_datalen. A data message with rm_datalen of 2047 or 2048 writes 1–2 fully device-controlled bytes past the end of the 2048-byte kmalloc(MCLBYTES, M_MBUFCL) cluster backing the mbuf (mclmeta_ctor, sys/kern/uipc_mbuf.c:608-624).

DragonFly synced this driver from FreeBSD r261544 (2014-02-06), before FreeBSD commit a51f9801806b ("Fix for unaligned IP-header ... Adjust a length check to include the 2-byte ethernet alignment while at it.", hselasky, 2015-11-06) fixed exactly this:

-   } else if (msg.rm_datalen > (uint32_t)MCLBYTES) {
+   } else if (msg.rm_datalen > (uint32_t)(MCLBYTES - ETHER_ALIGN)) {
...
        if (m != NULL) {
+           m->m_len = m->m_pkthdr.len = msg.rm_datalen + ETHER_ALIGN;
            m_adj(m, ETHER_ALIGN);

DragonFly's own shared helper uether_rxbuf() enforces the correct bound (sys/bus/u4b/net/usb_ethernet.c:578: if (len < ETHER_HDR_LEN || len > MCLBYTES - ETHER_ALIGN) return (1);) — only this driver's hand-rolled path diverges.

Reproduction (baseline, stock kernel)

The malicious usbredir RNDIS device (usbredir_rndis.py, driven via QEMU -device usb-redir) attaches as ue0 and pushes crafted RNDIS data messages on the bulk IN pipe:

urndis0: <vendor 0x0525 product 0xa4a2, class 2/0, rev 2.00/0.00, addr 2> on usbus0
ue0: <USB Ethernet> on urndis0
ue0: MAC address: 02:00:de:ad:be:ef
# host$ printf 'send 2046 36 1\nsend 2047 36 1\nsend 2048 36 1\n' | ctrl:45601
ue0  Ipkts=4  Ierrs=0  Ibytes=7641     # = 1500+2046+2047+2048, ALL accepted

2047 and 2048 are accepted on the stock driver — by the source-level arithmetic of the path taken, those copies ran 1 and 2 bytes past the cluster. ~2600 further 2048-length frames were pushed (with guest-side cluster churn) without a panic: the 2-byte write lands in the next 2048-byte slab chunk of DF's slab allocator (sys/kern/kern_slaballoc.c) — when that chunk is FREE its first word is the SLChunk.c_Next freelist pointer, so the write corrupts the low 16 bits of a slab freelist link; when it is in use it corrupts another packet's cluster (silent). The partial-pointer redirect stays inside mapped slab KVA, so no immediate fault — a silent, exploitable primitive, not a crashy one.

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

# host$ send 2046 / send 2047 / send 2048   (same PoC, patched module)
ue0  Ipkts=1  Ierrs=2  Ibytes=2046

2046 still accepted (no regression); 2047/2048 now rejected with IERRORS — exactly the lengths whose copies overflow.

Run it

See boot_rig.sh / boot_rig_cold.sh (QEMU rig), usbredir_rndis.py (the malicious device; control plane on TCP 45601), and VERDICT.md. Guest prerequisites: mv /boot/kernel/if_cdce.ko /root/ (cdce's VPI match on 0525:a4a2 otherwise claims the device — and panics via the DF-5334 bug), kldload if_urndis, ifconfig ue0 up.

DF-5396 VERDICT

Status: reproduced (memcorrupt / heap overflow via malicious USB device). Fix: validated on the guest (behavioral differential baseline vs patched).

Environment

• Host QEMU 7.2.22 (Debian), KVM, DF guest 6.5-DEVELOPMENT #0/#2 X86_64_GENERIC
• Malicious device: usbredir_rndis.py (this pack) — a full usbredir protocol device-side implementation serving a RNDIS gadget (0525:a4a2, control iface CDC/ACM/0xFF so urndis_non_huawei_host_devs matches, if_urndis.c:180-184) over -device usb-redir. The guest's urndis(4) runs its whole control channel (INIT/QUERY/SET) against attacker-chosen bytes, and the bulk IN pipe delivers fully crafted RNDIS REMOTE_NDIS_PACKET_MSG frames.
• cdce must be kept from loading (if_cdce.ko moved away): its VPI match on 0525:a4a2 wins probe priority and its own DF-5334 attach panic fires first.

How the reproduction works

1. boot_rig.sh boots the guest clean; kldload if_urndis; start usbredir_rndis.py; device_add usb-redir via the QEMU monitor. The guest attaches the device: ue0: MAC address: 02:00:de:ad:be:ef (the attacker device's MAC — proof the whole RNDIS control channel is ours).
2. ifconfig ue0 up → RNDIS INIT handshake (our INIT_CMPLT) → bulk transfers start.
3. Control plane (TCP 45601): send <datalen> <dataoffset> [count] queues a crafted packet message: rm_type=1, rm_len=8+36+datalen, rm_dataoffset=36, rm_datalen=datalen — a valid RNDIS data message by every check in urndis_bulk_read_callback (if_urndis.c:825-865) except the MCLBYTES bound at :859, which allows exactly the overflow.

Observed (baseline, stock if_urndis.ko)

ue0  Ipkts  Ierrs  Ibytes
     1      0      1500     (benign warm-up)
     4      0      7641     (1500 + 2046 + 2047 + 2048 — all accepted)

The 2047-byte frame copies 1 byte, the 2048-byte frame 2 bytes past the 2048-byte kmalloc(M_MBUFCL) cluster — by construction of the executed path (m_getcl → m_adj(2) → usbd_copy_out(rm_datalen)), there is no other allocation in play and no alternative sink.

~2600 additional 2048-frames + guest-side cluster churn (nc/dd UDP spray) produced no panic — expected: DF's slab allocator (kern_slaballoc.c:1555-1580) threads free 2048-byte chunks through the c_Next pointer stored in the chunk's first word, so the 2 controlled bytes corrupt the low 16 bits of a slab freelist link (or a neighboring in-use cluster's data). The partial pointer stays inside mapped slab KVA, so nothing faults — a silent corruption primitive.

Exploit chain (documented; not driven to uid=0 in this run)

1. Device + unprivileged local helper groom the 2048-byte slab zone: hold K clusters (UDP datagrams queued on a socket), free alternating ones so slab-freelist chunks with live c_Next links sit adjacent to the victim rx clusters.
2. One crafted frame with rm_datalen=2048 overwrites the low 16 bits of a free neighbor's c_Next with attacker data (the last 2 bytes of the RNDIS data payload).
3. On the next slab-layer pop, z_LChunks is re-pointed inside a 64 KB window; the following kmalloc(2048) returns an attacker-steered address. The next rx frame then writes up to 2046 controlled bytes there (usbd_copy_out into the "cluster").
4. With the standard no-KASLR/no-SMAP/SMEP guest image this is a kernel write primitive aimed at whatever occupies the steered address (e.g. adjacent slab zones holding credential-adjacent objects), with the packet content fully chosen by the device. Deterministic uid=0 needs per-boot heap reconnaissance (a leak or repeated partial-pointer probing); not completed in this session.

Fix validation

fix.diff (mirrors FreeBSD a51f980) applied to the guest's /usr/src, if_urndis.ko rebuilt and installed; same PoC traffic:

baseline:  2046/2047/2048 all accepted (Ipkts 4, Ierrs 0)  -> overflow executes
patched:   2046 accepted (Ipkts 1, Ibytes 2046), 2047/2048 rejected (Ierrs 2)

No regression: normal attach, INIT/QUERY/SET, and 2046-byte frames unchanged. The patched module was also exercised with the malformed descriptor device of DF-5397 (clean ENXIO) — both packs share this build.

Negative results (sanity chain audited at runtime)

• rm_len > actlen, rm_dataoffset >= actlen, rm_datalen > actlen, dataoffset+datalen+8 > actlen, rm_type != 1, rm_len < 44 are all correctly rejected (frames dropped, guest unharmed) — the wrap attempts (rm_dataoffset + rm_datalen + 8 overflow) are impossible because both fields are first individually bounded by actlen ≤ RNDIS_RX_MAXLEN (16384).
• Multi-packet messages (two valid messages in one transfer) parse correctly and terminate.
• TX path: m->m_pkthdr.len + sizeof(msg) > RNDIS_TX_MAXLEN correctly bounds the write frame; frame offsets x * RNDIS_TX_MAXLEN stay inside the 8*2048 DMA buffer.

Kernel references

• sys/bus/u4b/net/if_urndis.c:859 (bad bound), :865-877 (m_getcl + m_adj + usbd_copy_out sink)
• sys/kern/uipc_mbuf.c:608-624 (mclmeta_ctor: cluster = kmalloc(2048))
• sys/net/ethernet.h:41 (ETHER_ALIGN 2), sys/sys/param.h:497 (MCLBYTES 2048)
• sys/kern/kern_slaballoc.c:1555-1580 (free-chunk c_Next linkage)
• sys/bus/u4b/net/usb_ethernet.c:578 (the correct shared-helper bound)
• FreeBSD a51f9801806b43f453ead9a43d458f2d5ba541e6 (upstream fix)

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.