wifi: ath11k: add srng->lock for ath11k_hal_srng_ in monitor mode
Only affects Linux kernel builds using the ath11k Wi-Fi driver in full monitor mode, from 5.6 up to the fixed releases 6.6.123, 6.12.69 and 6.14.2.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 6.6.123, 6.12.69, 6.14.2
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
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
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
5.6
- KernelLinux
From 5.6.0 · fixed in 6.6.123; From 6.7.0 · fixed in 6.12.69; From 6.13.0 · fixed in 6.14.2
References 5
Questions about CVE-2024-58096
What does this mean?
The ath11k Wi-Fi driver's monitor mode could access a shared hardware ring buffer without holding the lock meant to protect it. Running full monitor mode triggers a kernel warning because of this missing lock.Source: git.kernel.org
Am I affected, and how do I check?
Kernels from 5.6.0 up to 6.6.123, from 6.7.0 up to 6.12.69, and from 6.13.0 up to 6.14.2 are in the affected ranges. The setup in question is full monitor mode on the ath11k driver, which you can check by looking at the kernel version with uname -r and whether the ath11k driver is loaded with lsmod.Source: git.kernel.org
What should I do about it?
Update to a fixed kernel: 6.6.123, 6.12.69, 6.14.2, or a later release in the same series. Stable branches that carry the fix are listed in the affected ranges above.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data