CVE-2024-56599

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, destroy_workqueue() 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 ath10ksdio_probe().

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 ath10ksdiohiftx_sg() won't be called anymore.

Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189