CVE-2024-56599: wifi: ath10k: avoid NULL pointer error during sdio remove
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10ksdioremove() will free sdio workqueue by destroyworkqueue(). But if CONFIGINITONFREEDEFAULTON is set to yes, kernel panic will happen: Call trace: destroyworkqueue+0x1c/0x258 ath10ksdioremove+0x84/0x94 sdiobusremove+0x50/0x16c devicereleasedriverinternal+0x188/0x25c devicedriverdetach+0x20/0x2c
This is because during 'rmmod ath10k', ath10ksdioremove() will call ath10kcoredestroy() before destroyworkqueue(). wiphydevrelease() will finally be called in ath10kcoredestroy(). This function will free struct cfg80211registereddevice rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIGINITONFREEDEFAULTON.
After device release, destroyworkqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10ksdioremove ->ath10kcoreunregister …… ->ath10kcorestop ->ath10khifstop ->ath10ksdioirqdisable ->ath10khifpowerdown ->deltimersync(&arsdio->sleeptimer) ->ath10kcoredestroy ->ath10kmacdestroy ->ieee80211freehw ->wiphyfree …… ->wiphydevrelease ->destroyworkqueue
Need to call destroyworkqueue() before ath10kcoredestroy(), free the work queue buffer first and then free pointer of work queue by ath10kcoredestroy(). This order matches the error path order in ath10ksdioprobe().
No work will be queued on sdio workqueue between it is destroyed and ath10kcoredestroy() is called. Based on the callstack above, the reason is: Only ath10ksdiosleeptimerhandler(), ath10ksdiohiftxsg() and ath10ksdioirqdisable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10kcoredestroy() in ath10khifpowerdown(). ath10ksdioirqdisable() only be called in ath10khifstop(). ath10kcoreunregister() will call ath10khifpowerdown() to stop hif bus, so ath10ksdiohiftxsg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Other sources
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2024-56599?
CVE-2024-56599 is classified as a medium severity vulnerability due to the potential for a NULL pointer dereference.
How do I fix CVE-2024-56599?
To fix CVE-2024-56599, upgrade to a version of the Linux kernel that is 6.12.5 or later.
Which versions of the Linux kernel are affected by CVE-2024-56599?
CVE-2024-56599 affects versions of the Linux kernel prior to 6.12.5.
What is the impact of CVE-2024-56599?
The impact of CVE-2024-56599 is a possible denial of service through a NULL pointer dereference during the removal of the ath10k driver.
Is there a workaround for CVE-2024-56599?
A workaround for CVE-2024-56599 is to avoid using the 'rmmod ath10k' command until the kernel is updated.