{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-58096", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-58096" ], "published": "2025-04-16T14:14:59Z", "summary": "wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode\n\nath11k_hal_srng_* should be used with srng->lock to protect srng data.\n\nFor ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),\nthey use ath11k_hal_srng_* for many times but never call srng->lock.\n\nSo when running (full) monitor mode, warning will occur:\nRIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]\nCall Trace:\n ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]\n ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]\n ? idr_alloc_u32+0x97/0xd0\n ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]\n ath11k_dp_service_srng+0x289/0x5a0 [ath11k]\n ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]\n __napi_poll+0x30/0x1f0\n net_rx_action+0x198/0x320\n __do_softirq+0xdd/0x319\n\nSo add srng->lock for them to avoid such warnings.\n\nInorder to fetch the srng->lock, should change srng's definition from\n'void' to 'struct hal_srng'. And initialize them elsewhere to prevent\none line of code from being too long. This is consistent with other ring\nprocess functions, such as ath11k_dp_process_rx().\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null, "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-58096" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/27ca8004ba93a0665faa6d477eaeb551e03de6c8" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/1d2178918efc928e11bed9631469ef79ff0a862a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b85758e76b6452740fc2a08ced6759af64c0d59a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/63b7af49496d0e32f7a748b6af3361ec138b1bd3" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.8, "cvss_v3_severity": "High", "scenario": "AV:A - The entire code path is driven by 802.11 frames received over the air into the ath11k monitor destination/status rings, so the attacker only needs to be within WiFi radio range of the target. Per kernel scoring guidance, WiFi frame injection is Adjacent.\nAC:L - The attacker controls both sides of the race by injecting frames \u2014 high-rate valid traffic drives the monitor status/dest NAPI (ext-IRQ groups 4-6) while malformed/error frames drive ath11k_dp_process_rxdma_err() on the same srng from groups 0-2 \u2014 and can widen the window arbitrarily by raising injection rate. The condition also fires spontaneously under normal load, as documented by the sibling fix 16c6c35c03ea reporting repeated invalid buf_id and RCU stalls on WCN6855.\nPR:N - A monitor-mode ath11k radio captures raw frames from any transmitter in range with no association, no 4-way handshake and no credentials of any kind, so the attacker needs zero privileges on the target. The vulnerable ring processing runs entirely pre-authentication on received frames.\nUI:N - Monitor/full-monitor capture is passive and continuous; the reap timer and NAPI poll the rings automatically with no victim action required. The attacker simply transmits frames into the air.\nS:U - The corruption is confined to kernel memory (SRNG descriptors, sk_buff heap objects, DMA mappings) within the same security authority. No VM, IOMMU or sandbox boundary is crossed.\nC:H - Desynchronized ring pointers cause stale/garbage descriptors to be parsed, and the resulting sw_cookie indexes pmon->link_desc_banks[] (size 8) with no bounds check, producing an out-of-array read whose vaddr/paddr are then dereferenced in ath11k_hal_rx_msdu_list_get() \u2014 an arbitrary kernel read primitive. The concurrent double-consumption of buf_ids additionally causes freed sk_buff contents to be read back as a hal_rx_desc.\nI:H - Two consumers resolving the same buf_id across non-atomic idr_find()/idr_remove() sections produce a double dma_unmap_single() and double dev_kfree_skb_any() \u2014 a double-free/use-after-free of an sk_buff, a well-known heap-corruption write primitive. ath11k_hal_srng_access_end() also publishes a torn tp to the device's shared pointer, letting the hardware DMA into buffers the host still owns.\nA:H - The same-series commit 16c6c35c03ea documents this exact monitor destination ring desynchronization causing an infinite reap loop, RCU stall and kernel crash on WCN6855. The lockdep_assert_held() failures also produce WARNs that panic on panic_on_warn systems, and the UAF/double-free crashes the kernel outright." } } }