Look up another CVE · open CVE-2026-98349 in the interactive tracker
CVE-2026-98349
wifi: libipw: reject too-short beacon and probe responses
Published 2026-10-06 (13 days ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-98349 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/wireless/intel/ipw2x00/libipw_rx.c
- What this is
- INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORTMAINTAINERS section matched on drivers/net/wireless/intel/ipw2x00/ · linux-wireless@vger.kernel.org · Maintained
- Kernel module
- libipw
Check it on the machine
grep -wE 'CONFIG_IPW2100|CONFIG_IPW2200|CONFIG_LIBIPW|CONFIG_WLAN|CONFIG_WLAN_VENDOR_INTEL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w libipwPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian does not build this code in 3 releases. It does build it in 1 release, so the answer depends on which release the machine runs.
- bookwormMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/arm64, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixie, forky, sidn
- M
- a module where it is built at all; some flavours do not build it
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_IPW2100, CONFIG_IPW2200, CONFIG_LIBIPW, CONFIG_WLAN, CONFIG_WLAN_VENDOR_INTEL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-10-06 (13 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.26%, higher than 16.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.14 | 5.10.271 | cee6f141b3be |
| 2.6.14 | 5.15.222 | 23afeb5d2bdf |
| 2.6.14 | 6.1.189 | 89959ff00a97 |
| 2.6.14 | 6.6.158 | 14ae269c1306 |
| 2.6.14 | 6.12.112 | ff756e664772 |
| 2.6.14 | 6.18.54 | 2c87bbc00dc9 |
| 2.6.14 | 7.2.8 | 19959fb60228 |
| 2.6.14 | 7.3 | 5ce5721e8cbe |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The malformed input is a beacon or probe response sent over the air. The ipw2100 isr_rx and ipw2200 ipw_rx paths only check for a 24-byte header before libipw_rx_mgt() passes the frame to libipw_process_probe_response(). This is an 802.11 management frame, so the attacker must be within radio range.
- AC:LAttack complexity, low
- Any beacon or probe response shorter than the 36-byte libipw_probe_response prefix triggers the bug every time. In libipw_network_init(), stats->len - sizeof(*beacon) wraps to about 65524 when truncated to u16. The attacker can send such frames repeatedly, and periodic automatic scans make the driver process probe responses.
- PR:NPrivileges required, none
- Beacons and probe responses are parsed before any association or authentication, so the sender needs no credentials or relationship with the victim station.
- UI:NUser interaction, none
- The driver processes management frames on its own once the interface is up, and periodic background scans process probe responses. No user action is needed.
- S:UScope, unchanged
- The out-of-bounds read happens in the kernel's libipw receive path, and its impact stays within the kernel's own security authority.
- C:LConfidentiality impact, low
- libipw_parse_info_param() reads up to about 64 KiB of adjacent heap past the RX skb. It copies only capped pieces (SSID, rates, WPA/RSN IEs) into the stored libipw_network, which shows up in scan results. The remote sender cannot read this back, and the leaked contents are not under its control.
- I:NIntegrity impact, none
- This is a read-only overrun. Every copy in libipw_parse_info_param() is bounded by the destination size (min() on ssid_len, rates_len, wpa_ie_len, rsn_ie_len), so no kernel memory is written out of bounds.
- A:HAvailability impact, high
- An unauthenticated sender can repeat the frame, and each one makes the parser read about 64 KiB past a roughly 3 KB RX buffer at a different heap position. That can reach unmapped memory and oops in the RX path, and it fires KASAN or KFENCE reports. Either one takes the system down.