Look up another CVE · open CVE-2026-98348 in the interactive tracker
CVE-2026-98348
wifi: libipw: reject too-short association 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-98348 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_handle_assoc_resp() reads the capability, status and aid fields of the 30-byte association response prefix and then computes the information element length as stats->len - sizeof(*frame) 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() turns a frame shorter than the fixed fields into a length near 64 KiB, and the parser then reads past the receive buffer. Both the ipw2100 and ipw2200 management receive paths reach this function having established only that the frame carries the generic 24-byte three-address header. 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.7% 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.15 | 5.10.271 | 766268b429ae |
| 2.6.15 | 5.15.222 | d70bdb84cf17 |
| 2.6.15 | 6.1.189 | 400b89217058 |
| 2.6.15 | 6.6.158 | 46aa75291056 |
| 2.6.15 | 6.12.112 | e3025ecdb205 |
| 2.6.15 | 6.18.54 | 14cb425ba1f3 |
| 2.6.15 | 7.2.8 | af1b69be19c3 |
| 2.6.15 | 7.3 | adb7118b7d2c |
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 an 802.11 Association Response management frame received over the air. ipw2100 (isr_rx path) and ipw2200 (ipw_handle_mgmt_packet) send it through libipw_rx_mgt() into libipw_handle_assoc_resp(). The attacker must be within WiFi radio range.
- AC:LAttack complexity, low
- The attacker only has to send an ASSOC_RESP frame of 24-29 bytes. The drivers check only for the 24-byte header, so stats->len - sizeof(*frame) (30) wraps to about 64K in the u16 length passed to libipw_parse_info_param(). No race or special state is involved.
- PR:NPrivileges required, none
- libipw_rx_mgt() processes management frames before any 802.11 authentication or key exchange. An unauthenticated nearby transmitter can inject the frame.
- UI:NUser interaction, none
- The frame is processed in the receive path as soon as the interface is up. The victim does nothing.
- S:UScope, unchanged
- The out-of-bounds read stays inside the host kernel's own memory and crosses no virtualization or IOMMU boundary.
- C:LConfidentiality impact, low
- libipw_parse_info_param() walks up to about 64KB of memory past the receive buffer. Those bytes only fill a local libipw_network on the stack, and through the QoS IE path the qos_data that goes to firmware. Nothing is returned to the attacker, so the disclosure is limited and indirect.
- I:NIntegrity impact, none
- The bug is read-only. Every copy from the parsed IEs is bounded (min() on ssid/rates, an exact-size check in libipw_read_qos_param_element) and lands in the fixed-size local network struct, so nothing is written out of bounds.
- A:HAvailability impact, high
- Iterating about 64KB of information elements past a few-KB skb/DMA receive buffer can hit unmapped pages (or KASAN/KFENCE) and oops the kernel. Any station in range can resend the short frame repeatedly.