CVE-2026-98349

What it actually does

Insufficient length validation in libipw_process_probe_response and libipw_network_init allows a 24-byte management frame header to trigger size_t subtraction wraparound, resulting in libipw_parse_info_param reading nearly 64 KiB beyond the receive buffer allocation.

Why it matters to the business

Wireless devices using affected ipw drivers may experience crashes or memory corruption when processing crafted 802.11 frames, leading to denial of service and potential code execution in kernel context on systems that rely on these legacy drivers.

How an attack unfolds

An attacker within radio range crafts a minimal 24-byte probe response or beacon frame and transmits it to a vulnerable station; the receive path skips the 36-byte prefix check, the length arithmetic wraps, and the parser dereferences attacker-controlled data beyond the allocation, enabling read or write primitives.

How to fix it

Apply the upstream patch that rejects frames shorter than the 36-byte beacon/probe response prefix before any fixed-field processing; rebuild and deploy the updated kernel on affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting libipw.c for an early length check against the 36-byte minimum before calling libipw_network_init; run the provided KUnit test case under KASAN to verify no out-of-bounds access occurs on short frames.

Typical attack path

1. Position within 802.11 range of target device using ipw2100 or ipw2200 hardware
2. Transmit a management frame containing only the 24-byte 802.11 header and no fixed fields
3. Trigger libipw_process_probe_response which calls libipw_network_init
4. Trigger wraparound in stats->len - sizeof(beacon) calculation
5. Cause out-of-bounds memory access inside libipw_parse_info_param

How to detect it

Review kernel logs for KASAN reports or oopses referencing libipw_parse_info_param or libipw_network_init after wireless frame reception; correlate with 802.11 probe response or beacon frames shorter than 36 bytes captured on the affected interface.

What your security team should do

• Prioritize kernel updates on any systems still using ipw2100 or ipw2200 wireless drivers
• Disable the affected wireless interfaces or replace hardware if updates cannot be applied promptly
• Monitor upstream stable kernels for the commit that adds the minimum-length rejection
• Audit wireless driver usage across the fleet and migrate away from legacy ipw hardware