CVE-2026-98186

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux WiFi drivers could let a nearby attacker read memory from your device or crash it by sending special wireless network signals.

Exploitation: Remote Unauthenticated
Attacker needs: None
Complexity: Low
Impact: Data Exposure
Component: OS kernel
Class: Buffer Overflow
Remediation: Patch
Effort: Low
Patch risk: Low

What it actually does

Out-of-bounds read in mwifiex_search_oui_in_ie() when an attacker-controlled RSN/WPA IE supplies an unchecked pairwise-cipher count, allowing up to 255*4 bytes to be read past the kmemdup()'d beacon buffer during scan-result parsing.

Why it matters to the business

A nearby attacker can trigger kernel memory disclosure or crashes on Linux devices with mwifiex WiFi hardware simply by broadcasting crafted beacons or probe responses, potentially leading to information leaks or denial of service without any user interaction.

How an attack unfolds

An attacker configures a rogue access point to emit beacons or probe responses containing a malicious RSN or WPA IE with an inflated pairwise-cipher count. When a vulnerable Linux device performs a WiFi scan, the mwifiex driver parses the IE without length validation, resulting in an out-of-bounds read from the beacon buffer.

How to fix it

Apply the upstream Linux kernel fix that passes the available IE length to mwifiex_search_oui_in_ie(), keeps the length signed, and rejects negative values before any arithmetic. Rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the presence of the length bound and signed negative-value check inside mwifiex_search_oui_in_ie(); verify that callers still pass the element but the walk is now limited by the supplied IE byte count.

Typical attack path

Attacker deploys a rogue AP emitting crafted beacon/probe-response frames
Victim device initiates WiFi scan and receives the malicious frames
mwifiex driver accepts the RSN/WPA IE based on element ID alone
mwifiex_search_oui_in_ie() reads attacker-supplied count and walks OUI list without bounds check
Kernel performs out-of-bounds read into adjacent memory of the kmemdup'd buffer

How to detect it

Inspect kernel logs and crash dumps for mwifiex-related oops or warnings during WiFi scan processing; search audit or system logs for unexpected beacon parsing activity from unknown BSSIDs.

mwifiex_search_oui_in_ie
has_ieee_hdr
has_vendor_hdr

What your security team should do

Immediately schedule kernel updates containing the mwifiex IE length fix
Prioritize devices that use mwifiex WiFi hardware for patching
Temporarily disable mwifiex scanning on high-risk endpoints until patched
Monitor vendor advisories for backported fixes in supported distributions

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length mwifiex_search_oui_in_ie() reads a pairwise-cipher (PTK) count from a beacon/probe-response RSN or WPA information element and then walks that many 4-byte OUIs, comparing each with memcmp(). The count comes straight from the (attacker-supplied) IE and is never checked against the element's own length, and the callers admit the element on element_id alone (has_ieee_hdr() / has_vendor_hdr(), no length check). A crafted RSN/WPA IE with a large pairwise count therefore makes the walk read up to 255 * 4 bytes past the element -- an out-of-bounds read of the kmemdup()'d beacon buffer, reachable from any AP whose beacon/probe response is processed during scan-result parsing. Pass the number of IE bytes available at the OUI list and bound the walk to the element. Keep the length signed and reject a negative value before any unsigned arithmetic, so a small or zero IE length cannot underflow to a large size_t and defeat the bound. Found by 0sec automated security-research tooling (https://0sec.ai).

Affected packages

Ecosystem	Package	Introduced	Fixed