CVE-2023-53532: wifi: ath11k: fix deinitialization of firmware resources
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix deinitialization of firmware resources
Currently, in ath11k_ahb_fw_resources_init(), iommu domain
mapping is done only for the chipsets having fixed firmware
memory. Also, for such chipsets, mapping is done only if it
does not have TrustZone support.
During deinitialization, only if TrustZone support is not there,
iommu is unmapped back. However, for non fixed firmware memory
chipsets, TrustZone support is not there and this makes the
condition check to true and it tries to unmap the memory which
was not mapped during initialization.
This leads to the following trace -
[ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
[ 83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers
.. snip ..
[ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 83.287228] pc : __iommu_unmap+0x30/0x140
[ 83.293907] lr : iommu_unmap+0x5c/0xa4
[ 83.298072] sp : ffff80000b3abad0
.. snip ..
[ 83.369175] Call trace:
[ 83.376282] __iommu_unmap+0x30/0x140
[ 83.378541] iommu_unmap+0x5c/0xa4
[ 83.382360] ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb]
[ 83.385666] ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb]
[ 83.392521] ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb]
[ 83.398248] platform_shutdown+0x20/0x2c
[ 83.403455] device_shutdown+0x16c/0x1c4
[ 83.407621] kernel_restart_prepare+0x34/0x3c
[ 83.411529] kernel_restart+0x14/0x74
[ 83.415781] __do_sys_reboot+0x1c4/0x22c
[ 83.419427] __arm64_sys_reboot+0x1c/0x24
[ 83.423420] invoke_syscall+0x44/0xfc
[ 83.427326] el0_svc_common.constprop.3+0xac/0xe8
[ 83.430974] do_el0_svc+0xa0/0xa8
[ 83.435659] el0_svc+0x1c/0x44
[ 83.438957] el0t_64_sync_handler+0x60/0x144
[ 83.441910] el0t_64_sync+0x15c/0x160
[ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0)
[ 83.449903] ---[ end trace 0000000000000000 ]---
This can be reproduced by probing an AHB chipset which is not
having a fixed memory region. During reboot (or rmmod) trace
can be seen.
Fix this issue by adding a condition check on firmware fixed memory
hw_param as done in the counter initialization function.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue affects ath11k Wi-Fi driver cleanup on certain AHB chipsets. The driver can try to unmap firmware memory that was never mapped, causing a kernel NULL pointer dereference during reboot or module removal. Business impact appears to be stability risk on affected Linux systems, not proven remote compromise.
Executive priority
Handle through normal kernel maintenance, with higher priority for wireless appliances or embedded platforms where reboot reliability matters. There is no supplied evidence of active exploitation or remote compromise, but affected systems can crash in operational lifecycle paths.
Technical view
In ath11k_ahb firmware resource deinitialization, the TrustZone check alone allowed iommu_unmap on non-fixed-memory chipsets where initialization did not create a mapping. The fix adds a firmware fixed-memory condition consistent with initialization. The supplied trace shows a crash path through __iommu_unmap during ath11k_ahb shutdown.
Likely exposure
Exposure is likely limited to Linux systems using ath11k AHB Wi-Fi chipsets without fixed firmware memory, across listed affected kernel ranges including 5.19 and early 6.1, 6.2, 6.3, and 6.4 versions. Generic Linux servers without this driver or hardware path are unlikely to be affected.
Exploitation context
The bundle does not show active exploitation, KEV listing, CVSS, CWE, or a remote attack path. The documented reproduction is probing an affected AHB chipset and observing the trace during reboot or module removal. Treat it as a kernel stability flaw unless vendor guidance adds security impact.
Researcher notes
The key condition is mismatch between firmware resource initialization and deinitialization for non-fixed-memory ath11k AHB chipsets. The patch scope appears narrow: gate unmapping on the same fixed firmware memory hardware parameter used when mapping. Security severity remains underspecified in the sources.
Mitigation direction
Apply a kernel stable update containing the referenced ath11k fix.
Use distribution or device-vendor kernels that include the backported patch.
Prioritize embedded or appliance systems using Qualcomm ath11k AHB Wi-Fi hardware.
Check vendor advisories if your kernel is downstream or heavily customized.
Validation and detection
Inventory systems loading the ath11k_ahb or ath11k driver.
Compare deployed kernel versions against the listed affected and fixed references.
Review crash logs for __iommu_unmap and ath11k_ahb shutdown traces.
After updating, confirm reboot or module lifecycle no longer triggers the trace.
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-2023-53532 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.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 1, 2025, 11:46 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.