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 ath11kahbfwresourcesinit(), 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: ath11kahb ath11k qmihelpers .. snip .. [ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 83.287228] pc : iommuunmap+0x30/0x140 [ 83.293907] lr : iommuunmap+0x5c/0xa4 [ 83.298072] sp : ffff80000b3abad0 .. snip .. [ 83.369175] Call trace: [ 83.376282] iommuunmap+0x30/0x140 [ 83.378541] iommuunmap+0x5c/0xa4 [ 83.382360] ath11kahbfwresourcedeinit.part.12+0x2c/0xac [ath11kahb] [ 83.385666] ath11kahbfreeresources+0x140/0x17c [ath11kahb] [ 83.392521] ath11kahbshutdown+0x34/0x40 [ath11kahb] [ 83.398248] platformshutdown+0x20/0x2c [ 83.403455] deviceshutdown+0x16c/0x1c4 [ 83.407621] kernelrestartprepare+0x34/0x3c [ 83.411529] kernelrestart+0x14/0x74 [ 83.415781] dosysreboot+0x1c4/0x22c [ 83.419427] arm64sysreboot+0x1c/0x24 [ 83.423420] invokesyscall+0x44/0xfc [ 83.427326] el0svccommon.constprop.3+0xac/0xe8 [ 83.430974] doel0svc+0xa0/0xa8 [ 83.435659] el0svc+0x1c/0x44 [ 83.438957] el0t64synchandler+0x60/0x144 [ 83.441910] el0t64sync+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 hwparam as done in the counter initialization function.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPLSILICONZ-1
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2023-53532?
CVE-2023-53532 has been classified with a severity that indicates potential risks associated with firmware resource deinitialization in the Linux kernel.
How do I fix CVE-2023-53532?
To fix CVE-2023-53532, you should update your Linux kernel to the latest version where this vulnerability has been addressed.
What impact does CVE-2023-53532 have?
CVE-2023-53532 could lead to improper handling of firmware resources, potentially causing system instability or security vulnerabilities.
In which software is CVE-2023-53532 present?
CVE-2023-53532 affects the Linux kernel, specifically in the ath11k driver for handling firmware resources.
Is my system at risk for CVE-2023-53532?
If you are running a vulnerable version of the Linux kernel, your system could be at risk for CVE-2023-53532.