Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-06T09:18:28.127Z",
  "pubdate": "2026-10-06T09:18:28.127Z",
  "executiveSummary": "A critical out-of-bounds read vulnerability exists in the Linux kernel's libipw library, specifically within the processing of management frames.\nThe vulnerability occurs due to insufficient length validation for beacon and probe response frames, leading to integer underflow during arithmetic operations.\nAn unauthenticated attacker within radio range can craft a malicious frame with a length shorter than the expected 36-byte prefix.\nWhen processed, the faulty calculation results in a large unsigned integer, causing the parser to treat a small, legitimate memory buffer as a 64 KiB structure.\nThis allows an attacker to trigger an out-of-bounds memory read, which may lead to information disclosure or system instability, such as kernel panics.\nThe flaw affects the libipw component used by drivers such as ipw2100 and ipw2200. Remediation requires implementing strict length checks before accessing fixed fields in management frames.",
  "technicalDetails": "The vulnerability resides within the libipw_process_probe_response() and libipw_network_init() functions, which are responsible for parsing 802.11 management frames. The root cause is an improper assumption regarding the minimum length of beacon and probe response frames. Specifically, the library expects these frames to contain a 36-byte header, while the hardware receive paths for ipw2100 and ipw2200 only guarantee the presence of a generic 24-byte three-address management header.\nThe exploitation flow begins when the kernel receives a malformed management frame shorter than 36 bytes. Within libipw_network_init(), the code calculates the length of the information elements (IEs) using the expression: stats->len - sizeof(*beacon).\nBecause 'stats->len' is a u16 type and 'sizeof(*beacon)' is a size_t, the subtraction is promoted to a size_t type. When 'stats->len' is less than 36 (e.g., 24 bytes), the result of this subtraction underflows, wrapping around to a extremely large value (65524).\nThis large value is subsequently truncated to a u16 and passed to the libipw_parse_info_param() function. The parser, operating under the assumption that the buffer is significantly larger than its actual allocation, proceeds to walk the receive buffer as if it contained nearly 64 KiB of data. This action reads memory locations residing outside the boundaries of the original buffer, leading to an out-of-bounds read.\nThe vulnerability is exposed to any network-adjacent attacker capable of injecting frames into the wireless medium. Successful exploitation allows for the reading of sensitive adjacent kernel memory, potentially revealing internal kernel data structures or cryptographic material, or triggering a kernel fault due to invalid memory access. Verification via KASAN (Kernel Address Sanitizer) has confirmed that the memory access occurs outside the intended range, validating the potential for memory corruption or information leak scenarios."
}