CVE-2026-98702

What it actually does

Invalid 320 MHz CSA bandwidth indication on non-6 GHz links bypasses validation, leaving vht_operation.chan_width uninitialized and read later, causing kernel panic when panic_on_warn is enabled.

Why it matters to the business

Wireless access points or clients running affected kernels can be crashed remotely, causing denial of service, loss of connectivity, and potential service disruption until the system is restarted.

How an attack unfolds

An attacker within wireless range crafts a Channel Switch Announcement frame advertising 320 MHz bandwidth on a non-6 GHz link; the mac80211 validator accepts it with a warning, proceeds to ieee80211_chandef_vht_oper with uninitialized state, and triggers a kernel panic on the target system.

How to fix it

Apply the upstream kernel patch that rejects the invalid 320 MHz CSA bandwidth before VHT conversion; update to a Linux kernel version containing the fix for mac80211 CSA handling.

How to confirm the fix worked

Confirm the patch is present by inspecting mac80211 channel definition code for the added rejection of 320 MHz bandwidth on non-6 GHz links; test by sending a 320 MHz CSA frame and verifying no warning or panic occurs.

Typical attack path

1. Attacker associates or is within range of target 802.11 device
2. Attacker transmits malformed CSA frame with 320 MHz bandwidth indication on non-6 GHz channel
3. mac80211 HT/VHT validator warns but continues without rejecting the definition
4. ieee80211_chandef_vht_oper reads uninitialized chan_width
5. Kernel panics when panic_on_warn is enabled

How to detect it

Review kernel logs for warnings or panics referencing mac80211, HT/VHT channel definition validator, or uninitialized vht_operation.chan_width; inspect wireless packet captures for CSA frames advertising 320 MHz bandwidth on non-6 GHz links.

• mac80211: .*320 MHz.*CSA
• vht_operation.chan_width uninitialized
• ieee80211_chandef_vht_oper
• Kernel panic triggered by CSA frame processing

What your security team should do

• Prioritize kernel updates on all Linux-based wireless devices and access points
• Disable panic_on_warn in production kernels where feasible to reduce impact
• Monitor wireless traffic for anomalous CSA frames as an interim detection measure
• Verify kernel version and apply patches within standard maintenance windows given low exploit maturity