CVE Tools

CVE-2026-98349

wifi: libipw: reject too-short beacon and probe responses

No known exploitation. EPSS puts it in the 17th percentile. Fixed versions are out.

Published Updated Sources: CVE.org, NVD

What to do

Find your product and version, then upgrade to the build on the right.

  • LinuxAffected: ≥ b453872c35cfcbdbf5a794737817f7d4e7b1b579, < cee6f141b3bebe62eb0363fd147acb52023935f0Upgrade to: cee6f141b3bebe62eb0363fd147acb52023935f0Affected: ≥ b453872c35cfcbdbf5a794737817f7d4e7b1b579, < 23afeb5d2bdfd34c8a0a661876291a4fa9978293Upgrade to: 23afeb5d2bdfd34c8a0a661876291a4fa9978293Affected: ≥ b453872c35cfcbdbf5a794737817f7d4e7b1b579, < 89959ff00a978f3172726d3d5f861ee6f1aae26dUpgrade to: 89959ff00a978f3172726d3d5f861ee6f1aae26dAffected: ≥ b453872c35cfcbdbf5a794737817f7d4e7b1b579, < 14ae269c1306053ddf1ccf37c4bd66e085a652d1Upgrade to: 14ae269c1306053ddf1ccf37c4bd66e085a652d1 + 4 more branchesStated by: CVE record

Versions as the sources state them. Full version matrix after sign-in

What it is

From the CVE record

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.

In plain language

No plain-language summary for this CVE yet.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS17th
CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.3% chance of exploitation activity in the next 30 days, which ranks it in the 17th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

3 events over 1 day, from the signal feeds we watch.

  1. Record updated
  2. Publishedrecord updated

Affected products

Technical detail

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H

Scored 7.1 by NVD.

How it is reached

  • Attack Vector AdjacentRequires access to the local network (e.g. same Wi-Fi, Bluetooth)
  • Attack Complexity LowNo special conditions — the attack can be reliably reproduced
  • Privileges Required NoneNo authentication required — anyone can exploit this
  • User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

  • Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

  • Confidentiality LowSome restricted information is disclosed, but limited in scope
  • Integrity NoneNo integrity impact
  • Availability HighTotal denial of service — the component is completely unavailable

Sources

Watch the software you run.

My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.

We'll flag the next CVE, public exploit or patch for Linux, not every advisory.