• File: sys/dev/netif/sn/if_sn.c
• Lines: 983, 989, 1005, 1006, 1016, 1038, 1041
• Severity: Medium
• CVSS: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U:C:L/I:H/A:H
• CWE: CWE-787 Out-of-bounds Write
• Confidence: certain

Summary

snread() reads an 11-bit BYTE COUNT from the SMC91C92 RX packet header (RLEN_MASK=0x07ff, range 0..2047) into a u_short packet_length and unconditionally subtracts 6 (status+count+control+unused overhead) before any validation.

If the card reports a value < 6 (a degenerate or bogus header — trivially produced by a malicious PCMCIA/PCIe NIC, or by any chip state that fails to set RS_ERRORS for a malformed frame), the u_short wraps to 65530..65535.

The wrapped value is then used directly as the count for insw(BASE + DATA_REG_W, data, packet_length >> 1) into a 2048-byte mbuf cluster (MCLGET), writing up to ~65534 bytes of port-IO data into kernel heap — a heap-corruption primitive.

The ODDFRAME +1 at line 1006 can additionally wrap 65535→0 in one of the six cases.

Root cause

if_sn.c:983 packet_length = inw(BASE + DATA_REG_W) & RLEN_MASK; — RLEN_MASK=0x07ff (if_snreg.h:381) yields 0..2047.

if_sn.c:989 packet_length -= 6; performs the subtraction in promoted int but assigns back to u_short packet_length (declared at if_sn.c:955), so values 0..5 wrap to 65530..65535 (u16 modulo).

The RS_ERRORS filter at if_sn.c:994 only inspects status bits, never the length value, so a length-without-error-bits is trusted unconditionally.

if_sn.c:1005-1006 if (status & RS_ODDFRAME) packet_length++; may add 1 (only the 5→65535→0 case resolves safely).

if_sn.c:1016 m->m_pkthdr.len = m->m_len = packet_length; propagates the wrap into mbuf metadata (m_len is int; 65530 fits as a positive value).

if_sn.c:1021 MCLGET(m, M_NOWAIT); allocates a cluster of exactly MCLBYTES=2048 bytes (sys/param.h:497, MCLSHIFT=11).

if_sn.c:1037-1038 data = mtod(m, u_char *); insw(BASE + DATA_REG_W, data, packet_length >> 1); — insw (sys/cpu/x86_64/include/cpufunc.h:390-397) is rep; insw writing cnt 16-bit words to addr; with packet_length=65530 it writes 32765 words = 65530 bytes into the 2048-byte cluster.

if_sn.c:1039-1041 the odd-byte tail (data += packet_length & ~1; *data = inb(...)) writes one more byte at offset 65530/65532/65534 — also far out of bounds.

The TX paths (snstart:376, snresume:585) have explicit > ETHER_MAX_LEN - ETHER_CRC_LEN caps; RX has none.

Threat

Attacker position 1 (most reliable): a malicious or compromised PCMCIA / PCIe NIC function (PC-Card passthrough to a QEMU/KVM guest, hostile ExpressCard NIC, or SMC91C92 silicon erratum) that asserts IM_RCV_INT, drains the driver's status read with no RS_ERRORS bits, and returns a BYTE COUNT < 6 on the driver's second DATA_REG_W read.

The driver reads both words directly from chip registers (if_sn.c:982-983) and trusts them unconditionally; no software bound catches the wrap.

Attacker position 2 (plausible but unproven on real silicon): an on-link L2 peer transmitting a frame that confuses the SMC91C92 EPH into emitting a degenerate packet header with no error bit; matches the threat model of the sibling NIC rxlength findings (DF-1410 if_xe, DF-1478 if_my, DF-1481 if_vr, DF-1490 if_tx, DF-1514 if_ste, DF-1519 if_lge, DF-1526 if_sf) — same defect class, rated Medium because default-config 10/100 silicon clamps legal frames to ≤1518 B and so a wire trigger is not demonstrated.

Default driver config sets RCR_STRIP_CRC at if_sn.c:1338, so byte count is frame+CRC-stripped+6; smallest valid ether frame (60 bytes post-strip) yields byte count 66 — so the underflow requires abnormal chip output.

Impact once triggered:

• (a) 100% deterministic kernel heap corruption (write of up to ~63500 bytes of mostly-attacker-controlled packet data past the 2 KB cluster into adjacent slab objects — mbufs, arpcom, file-descriptor tables, etc.);
• (b) near-certain near-immediate panic when the insw crosses an unmapped page boundary (cluster slabs are 2 KB / page aligned, so the write reaches an unmapped page within ~2 KB..4 KB), giving reliable local DoS;
• (c) with slab grooming to keep trailing pages mapped (spray RX clusters and place a victim slab object — e.g. another mbuf's m_ext function pointer — adjacent), the write yields a controlled kernel function-pointer overwrite → local unprivileged→root escalation on the standard NIC-heap-overflow template.

Exploit / PoC

Three PoC variants under findings/poc/DF-1551/.

(A) Malicious PCMCIA / QEMU-emulated SMC91C92: the emulated card asserts RCV_INT, and on the driver's POINTER|DATA reads returns status=0x0000 (no RS_ERRORS), byte_count=0x0002 (so packet_length -= 6 wraps to 65532), then streams ~32766 arbitrary 16-bit words back on the insw cycle.

The host driver writes those words into a 2048-byte mbuf cluster, overwriting the next ~30 slab objects.

Reproducible with a small qemu device-model patch or a standalone PCMCIA passthrough.

(B) Local kldload witness (no special hardware, proves the unbounded-write defect): a kld module that

1. walks devclass sn to find each sn_softc,
2. waits for IFF_UP so the RX path is armed,
3. on the next IM_RCV_INT, briefly pokes the card's FIFO pointer to a bogus pre-loaded packet header crafted in on-card memory whose BYTE COUNT field is 0x0000 with status 0x0000 (SMC91C92 allows host-written packet memory via PTR+DATA_REG_W with PTR_RCV clear), then triggers snread via a software interrupt.

snread computes packet_length=0-6=65530, m_len=65530, insw writes 32765 words = 65530 bytes into the next MCLGET cluster, crossing into adjacent slabs.

Build: cc -c -DKLDLOAD -I/sys poc_sn_rxunderflow.c; ld -d -r poc_sn_rxunderflow.o; kldload ./poc_sn_rxunderflow.ko.

Success: Fatal trap 12: page fault while in kernel mode inside insw/ether_input within milliseconds (A:H DoS), or — with a groom mode that pre-allocates 1024 RX clusters then sprays victim objects into the adjacent slab — a controlled function-pointer overwrite visible in dmesg.txt as execution hitting an attacker-controlled address (privilege escalation).

(C) Wire-level (uncertain on real SMC91C92 silicon): from a peer on the same L2 segment, sendp(Ether(dst=victim_mac)/LLC()/b'\\x00'*60, iface='eth0') while running tcpdump -i sn0 -w out.pcap -s 0 -X on the victim; inspect for kernel oops.

Capture env.txt (uname -a, ifconfig sn0, pciconf), run.log (full dmesg including panic), leak_sample.txt if escalation variant is used.

Recommended fix

Bound packet_length to the RX buffer geometry before any arithmetic, and perform the subtraction in signed int so underflow is caught explicitly.

Matches the fix pattern of DF-1410/1478/1481/1490/1514/1519/1526.

--- a/sys/dev/netif/sn/if_sn.c
+++ b/sys/dev/netif/sn/if_sn.c
@@ -980,6 +980,23 @@ read_another:
    status = inw(BASE + DATA_REG_W);
    packet_length = inw(BASE + DATA_REG_W) & RLEN_MASK;

+   /*
+    * Validate the NIC-reported BYTE COUNT before subtracting the
+    * 6-byte packet header overhead.  RLEN_MASK is 11 bits (0..2047);
+    * a malicious or buggy SMC91C92 (PCMCIA / PCIe passthrough /
+    * erratum) can return a degenerate header with BYTE COUNT < 6 and
+    * no RS_ERRORS bit set, which would wrap the u_short subtraction
+    * below to ~65530 and cause insw() to write ~63 KB past the
+    * 2 KB MCLGET cluster.  Reject anything that does not fit a legal
+    * post-CRC-strip Ethernet frame (60..1514) plus the 6-byte header.
+    */
+   if (packet_length < 6 + ETHER_MIN_LEN - ETHER_CRC_LEN ||
+       packet_length > MCLBYTES + 6) {
+       IFNET_STAT_INC(ifp, ierrors, 1);
+       goto out;
+   }
+
    /*
     * The packet length contains 3 extra words: status, length, and a
     * extra word with the control byte.

The lower bound 6 + ETHER_MIN_LEN - ETHER_CRC_LEN = 66 rejects the underflow (was 0..5); the upper bound MCLBYTES + 6 = 2054 is currently unreachable because RLEN_MASK caps at 2047, but defends the cluster against a future register-width change.

After this guard the existing packet_length -= 6 is safe.

Related findings

• DF-1410/DF-1478/DF-1481/DF-1490/DF-1514/DF-1519/DF-1526 (twins): same RX length OOB family.
• DF-1552 (sibling): chip_ids[15] OOB in same file.