CVE-2026-68125

What it actually does

The flaw is an integer underflow / bounds-check failure in the Linux kernel IEEE 802.15.4 MAC security path, specifically mac802154 LLSEC decryption/authentication handling. When processing a secured 802.15.4 frame, the kernel subtracts the expected authentication tag length from the received payload length without first confirming that the payload is at least as long as the tag. A malicious peer in radio range can send a secured frame with a payload shorter than the 4-, 8-, or 16-byte authentication tag, causing the subtraction to become negative and then be interpreted as a very large unsigned associated-data length. That oversized length is passed into the AEAD crypto path, causing the kernel to walk far beyond the actual packet scatterlist. The demonstrated outcome is a kernel general-protection fault under KASAN, making denial of service / kernel crash the primary expected impact; broader memory-corruption consequences cannot be ruled out without vendor-specific analysis, but reliable code execution is not indicated by the available information.

Why it matters to the business

Systems that use Linux IEEE 802.15.4 networking, such as some low-power wireless, IoT, sensor, industrial, building-automation, or gateway deployments, may be crashable by an attacker with nearby radio access. Exploitation does not require network-layer reachability from the internet, but it may require only physical proximity within 802.15.4 radio range. Operationally, this can interrupt telemetry, automation, gateway connectivity, or embedded services relying on the affected kernel path. The issue was published recently and is not currently listed in CISA KEV, not associated with ransomware, and has no reported exploit maturity in the provided data, but wireless-adjacent systems should still prioritize remediation because exploitation can be low-interaction once an attacker is in radio range.

How an attack unfolds

An attacker positions an IEEE 802.15.4-capable radio near a vulnerable Linux system that has mac802154/LLSEC processing enabled. The attacker transmits a crafted secured 802.15.4 frame whose payload is shorter than the authentication tag length declared or implied by the security configuration. The vulnerable kernel accepts the frame far enough to enter llsec_do_decrypt_auth(). During AEAD request preparation, the kernel computes the associated-data length using the payload length minus the authentication tag length, but because the payload is too short, the subtraction underflows. The resulting very large unsigned length is passed into the crypto AEAD decrypt routine. The crypto scatterwalk then reads/walks beyond the real frame buffer, leading to a kernel fault or panic. Successful exploitation is expected to cause denial of service of the affected host or device; persistence, credential theft, or remote code execution are not evidenced by the provided details.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or kernel maintainer that includes the fix to reject secured IEEE 802.15.4 frames whose payload is shorter than the authentication tag before AEAD processing. Where exact fixed package versions are not provided, track vendor advisories for CVE-2026-68125 or the mac802154 LLSEC fix described as rejecting frames shorter than the authentication tag. If immediate patching is not possible, reduce exposure by disabling unused IEEE 802.15.4 radios, unloading or blacklisting unused 802.15.4-related kernel modules where operationally safe, disabling LLSEC-secured 802.15.4 processing if not required, limiting physical/radio proximity to affected devices, and monitoring for unexplained kernel crashes or device reboots. Embedded and appliance vendors should backport the bounds check into maintained kernel trees rather than relying solely on upstream kernel version numbers.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or firmware build includes the vendor fix for this vulnerability. Source-level validation should confirm that the mac802154 LLSEC decryption/authentication path checks whether the received data length is less than the authentication tag length and rejects the frame before calculating associated-data length. Operational validation can include confirming that 802.15.4 interfaces or modules are disabled on systems that do not require them, and that patched systems remain stable when exposed in a controlled lab to malformed secured 802.15.4 frames with payloads shorter than 4, 8, or 16 bytes of authentication tag. Use caution when testing because vulnerable systems may crash.

Typical attack path

1. Identify a Linux-based target that has IEEE 802.15.4 radio support active and is within radio range.
2. Confirm or infer that secured 802.15.4 frame processing / LLSEC is enabled or reachable.
3. Transmit a malformed secured 802.15.4 frame with a payload shorter than the required authentication tag length.
4. Trigger the vulnerable mac802154 LLSEC decryption/authentication path in the kernel.
5. Cause the AEAD associated-data length calculation to underflow and be interpreted as a very large unsigned value.
6. Crash or destabilize the kernel through an out-of-bounds scatterlist walk in the crypto AEAD path.

How to detect it

Evidence of exploitation will usually appear as host instability rather than conventional network indicators, because the malicious input is an IEEE 802.15.4 radio frame and may not traverse IP networks or perimeter sensors. Review kernel logs from affected or potentially affected systems, including dmesg, journald, syslog, persistent crash logs, watchdog logs, and appliance diagnostic bundles. Look for general-protection faults, kernel panics, KASAN reports, or call traces involving mac802154, IEEE 802.15.4 LLSEC, AEAD crypto decryption, scatterwalk, or llsec_do_decrypt_auth(). Correlate crash times with 802.15.4 radio activity, device reboots, watchdog resets, or loss of sensor/gateway connectivity. Where available, analyze 802.15.4 sniffer captures for secured frames that are shorter than their expected authentication tag length, especially frames with security enabled and only 0-15 bytes of post-header payload when a 4-, 8-, or 16-byte MIC/tag is expected. Because no named threat actors or public exploitation are provided, treat matching crashes as suspicious but validate against benign driver bugs, hardware faults, and lab testing activity.

• llsec_do_decrypt_auth
• mac802154
• ieee802154
• IEEE 802.15.4
• crypto_aead_decrypt
• aead_request_set_ad
• scatterwalk
• general protection fault
• KASAN:
• BUG: KASAN
• kernel panic
• Oops:
• watchdog: BUG: soft lockup
• Payload shorter than authentication tag
• secured frame shorter than authentication tag

What your security team should do

• Inventory Linux systems, embedded gateways, appliances, and IoT/OT devices that expose IEEE 802.15.4, 6LoWPAN, Zigbee, Thread, or other stacks that may rely on the Linux mac802154 subsystem.
• Prioritize patching systems where 802.15.4 radios are active, physically accessible, deployed in shared spaces, or important to safety, automation, or telemetry operations.
• Apply vendor kernel, firmware, or appliance updates that contain the mac802154 LLSEC bounds-check fix as soon as available.
• Disable or remove unused 802.15.4 interfaces, radios, drivers, and kernel modules to eliminate exposure where the functionality is not required.
• Increase monitoring for kernel panics, general-protection faults, watchdog resets, and unexplained reboots on devices with 802.15.4 radios.
• For high-risk deployments, use 802.15.4 radio monitoring/sniffing to detect malformed secured frames with payloads shorter than the expected authentication tag length.
• Coordinate with device vendors for embedded products because the affected code may be present in customized or long-term-support kernel builds even when upstream version information is unclear.