Description
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: avoid NULL pointer error during sdio remove

When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
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

This is because during 'rmmod ath10k', ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *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 CONFIG_INIT_ON_FREE_DEFAULT_ON.

After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.

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

Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of work queue by
ath10k_core_destroy(). This order matches the error path order in
ath10k_sdio_probe().

No work will be queued on sdio workqueue between it is destroyed and
ath10k_core_destroy() is called. Based on the call_stack above, the
reason is:
Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and
ath10k_sdio_irq_disable() will queue work on sdio workqueue.
Sleep timer will be deleted before ath10k_core_destroy() in
ath10k_hif_power_down().
ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().
ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif
bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.

Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Published: 2024-12-27
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4076-1 linux-6.1 security update
Debian DLA Debian DLA DLA-4178-1 linux security update
EUVD EUVD EUVD-2024-53247 In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: 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 This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *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 CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. 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 Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Ubuntu USN Ubuntu USN USN-7379-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7379-2 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-7380-1 Linux kernel (Low Latency) vulnerabilities
Ubuntu USN Ubuntu USN USN-7381-1 Linux kernel (Low Latency) vulnerabilities
Ubuntu USN Ubuntu USN USN-7382-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7449-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7449-2 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7450-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7451-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7452-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7453-1 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7468-1 Linux kernel (Azure, N-Series) vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-2 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-4 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-5 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-6 Linux kernel (AWS FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-7 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7510-8 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7511-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-7511-2 Linux kernel (GCP FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7511-3 Linux kernel (GKE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7512-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-2 Linux kernel (GCP FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-4 Linux kernel (Oracle) vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-5 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-6 Linux kernel (IBM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-7 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-8 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7516-9 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7517-1 Linux kernel (Xilinx ZynqMP) vulnerabilities
Ubuntu USN Ubuntu USN USN-7517-2 Linux kernel (IBM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7517-3 Linux kernel (BlueField) vulnerabilities
Ubuntu USN Ubuntu USN USN-7518-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7523-1 Linux kernel (Raspberry Pi Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7524-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-7539-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-7540-1 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-7593-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7602-1 Linux kernel (Xilinx ZynqMP) vulnerabilities
Ubuntu USN Ubuntu USN USN-7640-1 Linux kernel (IoT) vulnerabilities
History

Mon, 03 Nov 2025 21:30:00 +0000

Type Values Removed Values Added
References

Mon, 03 Nov 2025 20:30:00 +0000

Type Values Removed Values Added
References

Fri, 02 May 2025 06:30:00 +0000


Thu, 13 Feb 2025 00:30:00 +0000

Type Values Removed Values Added
Metrics threat_severity

Low

threat_severity

Moderate


Thu, 23 Jan 2025 17:15:00 +0000


Thu, 09 Jan 2025 15:45:00 +0000


Wed, 08 Jan 2025 22:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Weaknesses CWE-476
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel

Mon, 30 Dec 2024 01:30:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Fri, 27 Dec 2024 15:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: 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 This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *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 CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. 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 Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Title wifi: ath10k: avoid NULL pointer error during sdio remove
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T20:55:34.718Z

Reserved: 2024-12-27T14:03:06.011Z

Link: CVE-2024-56599

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Modified

Published: 2024-12-27T15:15:19.307

Modified: 2025-11-03T21:18:04.333

Link: CVE-2024-56599

cve-icon Redhat

Severity : Moderate

Publid Date: 2024-12-27T00:00:00Z

Links: CVE-2024-56599 - Bugzilla

cve-icon OpenCVE Enrichment

No data.

Weaknesses