CVE-2024-58096: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode
ath11k_hal_srng_* should be used with srng->lock to protect srng data.
For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
they use ath11k_hal_srng_* for many times but never call srng->lock.
So when running (full) monitor mode, warning will occur:
RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
Call Trace:
? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
? idr_alloc_u32+0x97/0xd0
ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
__napi_poll+0x30/0x1f0
net_rx_action+0x198/0x320
__do_softirq+0xdd/0x319
So add srng->lock for them to avoid such warnings.
Inorder to fetch the srng->lock, should change srng's definition from
'void' to 'struct hal_srng'. And initialize them elsewhere to prevent
one line of code from being too long. This is consistent with other ring
process functions, such as ath11k_dp_process_rx().
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Security readout for executives and security teams
Plain-English summary
A missing lock in Linux’s ath11k Wi-Fi driver can cause unsafe concurrent access while monitor or full-monitor mode is active. The supplied record rates it high severity, but its description demonstrates kernel warnings rather than confirmed data theft, modification, or system takeover.
Executive priority
Prioritize patch verification on ath11k systems used for wireless monitoring. Routine endpoints not using ath11k monitor mode appear less exposed. Treat the high score seriously, while recognizing that the supplied evidence does not establish real-world compromise or active exploitation.
Technical view
Monitor-mode receive paths call ath11k hardware ring functions repeatedly without holding the ring lock. The kernel fix adds locking around affected processing in ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(). The record assigns CVSS 3.1 8.8 with adjacent-network reachability, although the supplied technical evidence only documents warnings.
Likely exposure
Exposure is limited to Linux systems using supported ath11k wireless hardware with monitor or full-monitor mode active. The bundle flags versions including 5.6, 6.6.123, 6.12.69, 6.14.2, and 6.15, but its flattened version data is insufficient for precise distribution-level conclusions.
Exploitation context
The supplied record is not in CISA KEV and provides no evidence of active exploitation or a public exploit. Its adjacent-network CVSS vector suggests an attacker would need nearby network access, but the bundle does not explain a proven path from wireless traffic to confidentiality, integrity, or availability impact.
Researcher notes
The core defect is missing synchronization around shared ath11k SRNG state in two monitor-mode receive paths. The fix changes ring variables from void pointers to struct hal_srng pointers so their locks are accessible. No CWE is assigned. Validate backports by code presence because distribution version numbering may differ.
Mitigation direction
Apply the appropriate vendor-supported kernel update containing the referenced ath11k locking fix.
Consult the Linux distribution’s advisory for exact affected and fixed package versions.
Where operationally acceptable, avoid ath11k monitor and full-monitor modes until patched.
Prioritize wireless sensors, capture appliances, and research systems that intentionally enable monitor mode.
Validation and detection
Inventory systems loading the ath11k driver and identify their kernel package versions.
Determine whether monitor or full-monitor mode is enabled during normal operation.
Compare installed kernels against distribution advisories and the referenced stable commits.
Review kernel logs for ath11k ring warnings or traces resembling the supplied call stack.
After updating, confirm the vendor-fixed kernel is running and monitor-mode workloads remain stable.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-58096 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
5Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.