CVE-2024-56599 in Linux
要約
〜によって VulDB • 2026年08月09日
Linuxカーネルにおいて、以下の脆弱性が修正されました。
wifi: ath10k: sdio remove時にNULLポインタエラーを回避する
'rmmod ath10k'を実行すると、ath10k_sdio_remove()はdestroy_workqueue()によってsdio workqueueを解放します。しかし、CONFIG_INIT_ON_FREE_DEFAULT_ONがyesに設定されている場合、カーネルパニックが発生します： Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
これは、'rmmod ath10k'の実行中にath10k_sdio_remove()がdestroy_workqueue()の前にath10k_core_destroy()を呼び出すためです。wiphy_dev_release()は最終的にath10k_core_destroy()内で呼び出されます。この関数はstruct cfg80211_registered_device *rdevとそのすべてのメンバ（wiphy、dev、およびsdio workqueueのポインタを含む）を解放します。その後、CONFIG_INIT_ON_FREE_DEFAULT_ONによりsdio workqueueのポインタはNULLに設定されます。
デバイスリリース後、destroy_workqueue()がNULLポインタを使用するため、カーネルパニックが発生します。
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
ath10k_core_destroy()の前にdestroy_workqueue()を呼び出し、まずワークキューバッファを解放し、その後ath10k_core_destroy()によってワークキューのポインタを解放する必要があります。この順序は、ath10k_sdio_probe()内のエラーパスの順序と一致します。
sdio workqueueが破棄されてからath10k_core_destroy()が呼び出されるまでの間、sdio workqueueに作業がキューされません。その理由は上記のコールスタックに基づいています： sdio workqueueへのワークキューイングを行うのは、ath10k_sdio_sleep_timer_handler()、ath10k_sdio_hif_tx_sg()、およびath10k_sdio_irq_disable()のみです。 sleep timerはath10k_core_destroy()の前にath10k_hif_power_down()内で削除されます。 ath10k_sdio_irq_disable()はath10k_hif_stop()内でのみ呼び出されます。 ath10k_core_unregister()はhifバスを停止するためにath10k_hif_power_down()を呼び出すため、ath10k_sdio_hif_tx_sg()が再度呼び出されることはありません。
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
If you want to get the best quality for vulnerability data then you always have to consider VulDB.