CVE-2026-98349 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: libipw: reject too-short beacon and probe responses
libipw_process_probe_response() and the libipw_network_init() call it makes assume the frame contains the full 36-byte beacon and probe response prefix, but the ipw2100 and ipw2200 receive paths only establish that a management frame carries the generic 24-byte three-address header.
libipw_network_init() then computes the information element length as
stats->len - sizeof(*beacon)
stats->len is a u16 and sizeof() has type size_t, so the subtraction is evaluated as size_t and wraps instead of going negative. Truncating that to the u16 length parameter of libipw_parse_info_param() yields 65524 for a 24-byte beacon, and the parser then walks the receive buffer as if it held almost 64 KiB of information elements, reading past the allocation.
Reject the frame before any fixed field is touched.
Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel vulnerability identified within the wifi libipw subsystem represents a critical out-of-bounds read condition arising from improper validation of input data lengths in wireless management frame processing functions. Specifically, the issue resides in the interaction between libipw_process_probe_response and its internal call to libipw_network_init. These routines operate under the assumption that incoming beacon and probe response frames contain a full thirty-six-byte prefix structure comprising fixed fields and information elements. However, the underlying receive paths for ipw2100 and ipw2200 hardware drivers only verify the presence of a generic twenty-four-byte three-address header common to most management frames. This discrepancy creates a scenario where shorter-than-expected frames are processed without adequate bounds checking against the actual buffer size available in memory.
The core technical flaw is rooted in integer arithmetic type mismatch leading to an underflow condition that manifests as a massive positive value. When libipw_network_init calculates the length of information elements by subtracting the expected beacon structure size from the total frame length stored in stats->len, it performs this operation using unsigned types. Since stats->len is defined as a u16 and sizeof returns a size_t, the subtraction result is promoted to an unsigned integer type. If the incoming frame contains only the minimum twenty-four-byte header rather than the expected thirty-six bytes, the mathematical result becomes negative in signed arithmetic but wraps around to a large positive value when treated as unsigned. This truncated length value, approximately sixty-five thousand five hundred and twenty-four bytes for a minimal frame, is then passed to libipw_parse_info_param.
This erroneous length parameter causes the parser to iterate through memory locations far beyond the allocated buffer boundaries associated with the received packet. The function attempts to read information element data from addresses that do not belong to the current network interface or socket buffer context. Such out-of-bounds reads can lead to kernel panic due to invalid memory access, leakage of sensitive kernel stack contents to user space if subsequent operations copy this data, or potential denial of service conditions triggered by malformed packets sent over the wireless medium. The vulnerability is particularly dangerous because it exploits standard management frame structures that are routinely transmitted during network discovery and association processes, allowing remote attackers to trigger the flaw simply by broadcasting crafted probe responses or beacons within range.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound as the root cause of the incorrect length calculation, which subsequently leads to CWE-125 Out-of-bounds Read due to the excessive iteration over memory buffers. In terms of adversary tactics, exploiting this flaw would fall under ATT&CK technique T1046 Network Service Scanning if used for reconnaissance or potentially T1078 Valid Accounts if leveraged in conjunction with other exploits to gain unauthorized access through privilege escalation following a kernel crash dump analysis. The attack vector is remote and requires no authentication, making it accessible to any wireless client capable of transmitting management frames within the signal range of the affected device.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that enforces strict length validation before processing fixed fields in beacon and probe response frames. System administrators should ensure their systems are updated with the latest stable kernel versions containing this fix, particularly for devices utilizing ipw2100 or ipw2200 wireless adapters. For environments where immediate patching is not feasible, deploying network intrusion detection signatures that identify abnormally short management frames lacking expected information element structures can provide a layer of defense against exploitation attempts. Additionally, enabling kernel hardening features such as KASAN in production environments may help detect similar memory safety violations during runtime testing phases before they reach end users.