Cloudanix VulnDB

CVE-2026-68362

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux WiFi driver can cause the system to crash when wireless hardware fails to start correctly and then tries to recover.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference triggered when ATH11K_FLAG_REGISTERED is set despite firmware ready failure, leaving SRNG structures uninitialized so that subsequent SSR restart paths dereference them in ath11k_hal_srng_access_begin.

Why it matters to the business

Kernel crashes on WiFi-enabled Linux systems can interrupt wireless connectivity, cause unplanned reboots, and require manual intervention or automated recovery, increasing operational overhead especially on servers or embedded devices using ath11k hardware.

How an attack unfolds

An attacker or environmental condition causes ath11k_core_qmi_firmware_ready to fail after the flag is unconditionally set; later SSR triggers the restart path that walks uninitialized SRNG rings, producing the NULL dereference and crash. No remote code execution path is described.

How to fix it

Apply the upstream fix that guards flag setting, skips firmware_ready when already registered, and sets ATH11K_FLAG_QMI_FAIL on error; rebuild and deploy the corrected kernel image to all affected systems.

How to confirm the fix worked

Confirm the three flag-handling changes are present in the ath11k source; boot the patched kernel, simulate firmware-ready failure, then trigger SSR and verify no NULL dereference occurs in ath11k_hal_srng_access_begin.

Typical attack path

  1. Trigger QMI firmware ready event that fails inside ath11k_core_qmi_firmware_ready
  2. Driver still sets ATH11K_FLAG_REGISTERED leaving inconsistent state
  3. Initiate SSR or driver restart
  4. ath11k_core_restart calls ath11k_ce_cleanup_pipes which invokes ath11k_hal_srng_access_begin on uninitialized members
  5. NULL dereference produces kernel oops or panic

How to detect it

Search kernel logs and dmesg for ath11k_hal_srng_access_begin call traces, ath11k_ce_cleanup_pipes failures, and NULL pointer dereference oops occurring after ATH11K_QMI_EVENT_FW_READY; correlate with ath11k module load or SSR timestamps.

What your security team should do

  • Prioritize kernel update on all systems exposing ath11k WiFi within the next maintenance window given 76 days since disclosure
  • Monitor kernel logs for ath11k oops signatures during firmware load or SSR events
  • Test the patched driver under simulated QMI failure and SSR conditions before broad rollout

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1

Affected packages

Ecosystem Package Introduced Fixed