Description
ieee802154_decipher_data_frame() in subsys/net/l2/ieee802154/ieee802154_frame.c computed payload_len = net_pkt_get_len(pkt) - ll_hdr_len - authtag_len without first checking that the received frame is at least ll_hdr_len + authtag_len bytes long. All three variables are uint8_t, 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 ieee802154_decrypt_auth() and on to the CCM operation as cipher_pkt.in_len/out_buf_max, with apkt->tag pointing at frame + ll_hdr_len + payload_len. 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 ieee802154_validate_frame() 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 CONFIG_NET_L2_IEEE802154_SECURITY option, select a crypto device via CONFIG_NET_L2_IEEE802154_SECURITY_CRYPTO_DEV_NAME, and have established a security session with a level other than IEEE802154_SECURITY_LEVEL_NONE; with security disabled or at level NONE the tag length is zero and no underflow occurs. The fix rejects frames shorter than ll_hdr_len + authtag_len before the subtraction, and adds the matching guard on the transmit side in ieee802154_create_data_frame().
Published: 2026-10-07
Score: 8.1 High
EPSS: < 1% Very Low
KEV: No
Impact: Memory corruption and denial of service
Action: Apply patch
AI Analysis

Impact

An integer underflow in the IEEE 802.15.4 frame decryption code causes the calculated payload length to wrap into a large value when a frame is shorter than the expected authentication tag. The resulting large length leads to out‑of‑bounds reads and writes into the network buffer pool, corrupting packet and allocator metadata. This flaw is categorized as an improper arithmetic and out‑of‑bounds access (CWE‑191, CWE‑787) and primarily results in memory corruption and service disruption, not in direct information disclosure.

Affected Systems

The vulnerability affects the Zephyr project’s Zephyr RTOS, specifically any configuration that enables the experimental CONFIG_NET_L2_IEEE802154_SECURITY option with a non‑NONE security level. No specific product versions are listed in the input, so it applies to all builds that compile with this option enabled.

Risk and Exploitability

The CVSS score of 8.1 indicates high severity. EPSS is not available, and the vulnerability is not listed in the CISA KEV catalog. The flaw can be triggered by any device that transmits a crafted short frame within radio range; no key material or prior authentication is needed, and the attacker need not know the internal state to corrupt memory. The exposure is limited to configurations that enable security, but once triggered the attack can cause application crashes or memory corruption across the system.

Generated by OpenCVE AI on October 7, 2026 at 10:38 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Download and apply the Zephyr RTOS update that removes the underflow check and adds a guard against short frames (commit 6d721de13a6026808f75578ecfee95a3592d5264).
  • If an immediate update is not possible, reconfigure the system to disable CONFIG_NET_L2_IEEE802154_SECURITY or set the security level to IEEE802154_SECURITY_LEVEL_NONE, which eliminates the vulnerable authentication tag logic.
  • Implement a firewall or radio filter to block malformed frames from unauthorized devices while monitoring the system for abnormal memory faults or crashes.

Generated by OpenCVE AI on October 7, 2026 at 10:38 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 07 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Wed, 07 Oct 2026 11:00:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Wed, 07 Oct 2026 09:15:00 +0000

Type Values Removed Values Added
Description ieee802154_decipher_data_frame() in subsys/net/l2/ieee802154/ieee802154_frame.c computed payload_len = net_pkt_get_len(pkt) - ll_hdr_len - authtag_len without first checking that the received frame is at least ll_hdr_len + authtag_len bytes long. All three variables are uint8_t, 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 ieee802154_decrypt_auth() and on to the CCM operation as cipher_pkt.in_len/out_buf_max, with apkt->tag pointing at frame + ll_hdr_len + payload_len. 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 ieee802154_validate_frame() 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 CONFIG_NET_L2_IEEE802154_SECURITY option, select a crypto device via CONFIG_NET_L2_IEEE802154_SECURITY_CRYPTO_DEV_NAME, and have established a security session with a level other than IEEE802154_SECURITY_LEVEL_NONE; with security disabled or at level NONE the tag length is zero and no underflow occurs. The fix rejects frames shorter than ll_hdr_len + authtag_len before the subtraction, and adds the matching guard on the transmit side in ieee802154_create_data_frame().
Title Integer underflow in IEEE 802.15.4 frame decryption leads to out-of-bounds read and write
Weaknesses CWE-191
CWE-787
References
Metrics cvssV3_1

{'score': 8.1, 'vector': 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-10-15T22:10:23.920Z

Reserved: 2026-08-06T18:36:12.842Z

Link: CVE-2026-19186

cve-icon Vulnrichment

Updated: 2026-10-07T18:01:16.908Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-07T09:17:05.290

Modified: 2026-10-15T23:17:35.903

Link: CVE-2026-19186

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-07T10:45:07Z

Weaknesses
  • CWE-191

    Integer Underflow (Wrap or Wraparound)

  • CWE-787

    Out-of-bounds Write