CVE-2026-19186: Integer underflow in IEEE 802.15.4 frame decryption leads to out-of-bounds read and write
ieee802154decipherdataframe() in subsys/net/l2/ieee802154/ieee802154frame.c computed payloadlen = netpktgetlen(pkt) - llhdrlen - authtaglen without first checking that the received frame is at least llhdrlen + authtaglen bytes long. All three variables are uint8t, so a frame whose payload is shorter than the configured authentication tag makes the subtraction wrap around to a large value (up to 255).
The wrapped length is passed unchanged to ieee802154decryptauth() and on to the CCM operation as cipherpkt.inlen/outbufmax, with apkt->tag pointing at frame + llhdrlen + payloadlen. Because the receive buffer is allocated to the exact length of the frame received from the radio driver, the crypto layer then reads several hundred bytes past the end of the packet buffer and writes the same number of decrypted bytes back over it in place. The frame's authentication tag is only verified after this processing has taken place, so no key material, association or prior authentication is needed — a single crafted short frame from any device in radio range is sufficient. Frame validation in ieee802154validateframe() does not prevent it: a data frame is accepted with a one-byte payload.
The result is an out-of-bounds read and an out-of-bounds write of up to roughly 240 bytes into the adjacent network-buffer pool, corrupting other packets or allocator metadata and typically faulting the target. The out-of-bounds content is not attacker-chosen (it is ciphertext XOR keystream over out-of-bounds memory) and the frame is dropped when tag verification fails, so the primary impact is memory corruption and denial of service rather than information disclosure.
Exposure is limited to configurations that enable the experimental CONFIGNETL2IEEE802154SECURITY option, select a crypto device via CONFIGNETL2IEEE802154SECURITYCRYPTODEVNAME, and have established a security session with a level other than IEEE802154SECURITYLEVELNONE; with security disabled or at level NONE the tag length is zero and no underflow occurs. The fix rejects frames shorter than llhdrlen + authtaglen before the subtraction, and adds the matching guard on the transmit side in ieee802154createdataframe().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In ieee802154_decipher_data_frame(), reject frames shorter than ll_hdr_len + authtag_len before computing payload_len or performing the subtraction; add the matching length guard in ieee802154_create_data_frame() on the transmit side.
Event History
Frequently Asked Questions
Does an attacker need IEEE 802.15.4 credentials, key material, or an existing association?
No. A single crafted short frame from any device in radio range is sufficient; no key material, association, or prior authentication is required.
Is authentication-tag verification sufficient to prevent exploitation?
No. The crypto processing that performs the out-of-bounds read and write occurs before the frame authentication tag is verified.
What kind of frame triggers the condition?
A received data frame whose payload is shorter than the configured authentication-tag length can cause the unsigned payload-length calculation to wrap to a large value.
How can a deployment be exposed?
Exposure requires reception of crafted IEEE 802.15.4 frames from an attacker within radio range. The receive buffer is sized to the actual received frame, so the wrapped length causes processing beyond that buffer.