CVE-2026-75083: Integer underflow of the radio-reported frame length causes an out-of-bounds write in the NXP KW41Z IEEE 802.15.4 driver
The receive path of the NXP KW41Z IEEE 802.15.4 driver, kw41zrx() in drivers/ieee802154/ieee802154kw41z.c, computed the payload size as pktlen = len - KW41ZFCSLENGTH in a uint8t, where len is the frame length reported by the radio. The interrupt handler kw41zisr() obtained that length from the RXFRAMELENGTH field of the ZLL IRQSTS register — a copy of the PHY header length byte of the frame received over the air — and only rejected the value zero. A reported length of one therefore underflowed to pktlen == 255.
Because the packet is allocated with NETAFUNSPEC on a non-Ethernet L2, netpktrxallocwithbuffer() does not clamp the request to the interface MTU; with the default fixed-size buffer pool (CONFIGNETBUFFIXEDDATASIZE, CONFIGNETBUFDATASIZE=128) the allocation succeeded as a chain of two fragments. The subsequent register-to-buffer copy loops write into the first fragment only, so 255 bytes were written into a 128-byte netbuf data block, overrunning it by up to 127 bytes into adjacent network-buffer-pool memory, and reading up to 128 bytes past the end of the radio's PKTBUFFERRX register array.
The length field originates from an unauthenticated frame transmitted by any device within 802.15.4 radio range, and is captured by the hardware at PHY-header time — before frame filtering has completed — while the handler samples it after clearing the interrupt status, so an attacker flooding frames with a length byte of one can drive the underflow. The impact is memory corruption in the shared receive buffer pool from interrupt context, most plausibly a crash or corruption of other packets' data; the overflowing bytes are radio register contents rather than attacker-authored data, which bounds the integrity impact.
The fix rejects any length below KW41ZFCSLENGTH and additionally verifies netbuftailroom() of the first fragment before the copy loops, which also covers the CONFIGNETL2OPENTHREAD variant of the size computation.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to an attacker?
Deployments using the NXP KW41Z IEEE 802.15.4 driver receive the attacker-controlled length from frames transmitted over the air. The adjacent-network attack vector means the attacker must be within radio communication range.
Does exploitation require the attacker to authenticate, have device privileges, or induce user interaction?
No. The length field comes from an unauthenticated received frame, and the provided vector specifies no privileges and no user interaction.
Are default network-buffer settings affected?
Yes. With the default fixed-size buffer pool, where CONFIG_NET_BUF_DATA_SIZE is 128, the oversized allocation can succeed as two fragments, but the copy writes 255 bytes into the first 128-byte fragment.
What memory corruption occurs when the malformed length is accepted?
A reported frame length of one underflows the payload length to 255. This can overrun the first network-buffer data block by up to 127 bytes and can also read up to 128 bytes past the radio's PKT_BUFFER_RX register array.
How can maintainers determine whether their source includes the correction?
No fixed version is provided. Compare the source used for the build with the referenced Zephyr commit 51d71864578c08eb1a1201f87b46ec81c8609d62, particularly the KW41Z receive and interrupt handling paths.