CVE-2024-40979: Vulnerability in Linux Linux
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix kernel crash during resume Currently during resume, QMI target memory is not properly handled, resulting in kernel crash in case DMA remap is not supported: BUG: Bad page state in process kworker/u16:54 pfn:36e80 page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80 page dumped because: nonzero _refcount Call Trace: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs ath12k_qmi_free_target_mem_chunk ath12k_qmi_msg_mem_request_cb The reason is: Once ath12k module is loaded, firmware sends memory request to host. In case DMA remap not supported, ath12k refuses the first request due to failure in allocating with large segment size: ath12k_pci 0000:04:00.0: qmi firmware request memory request ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144 ath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size ath12k_pci 0000:04:00.0: qmi delays mem_request 2 ath12k_pci 0000:04:00.0: qmi firmware request memory request Later firmware comes back with more but small segments and allocation succeeds: ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 Now ath12k is working. If suspend is triggered, firmware will be reloaded during resume. As same as before, firmware requests two large segments at first. In ath12k_qmi_msg_mem_request_cb() segment count and size are assigned: ab->qmi.mem_seg_count == 2 ab->qmi.target_mem[0].size == 7077888 ab->qmi.target_mem[1].size == 8454144 Then allocation failed like before and ath12k_qmi_free_target_mem_chunk() is called to free all allocated segments. Note the first segment is skipped because its v.addr is cleared due to allocation failure: chunk->v.addr = dma_alloc_coherent() Also note that this leaks that segment because it has not been freed. While freeing the second segment, a size of 8454144 is passed to dma_free_coherent(). However remember that this segment is allocated at the first time firmware is loaded, before suspend. So its real size is 524288, much smaller than 8454144. As a result kernel found we are freeing some memory which is in use and thus cras ---truncated---
AI Analysis
Technical Summary
CVE-2024-40979 is a vulnerability in the Linux kernel's ath12k wireless driver, specifically affecting the handling of memory during system resume operations. The ath12k driver manages Qualcomm Atheros Wi-Fi chipsets. The issue arises during the resume phase after a system suspend, where the firmware requests memory segments from the host. Initially, the firmware requests large memory segments, but if DMA remapping is not supported, these allocations fail. The firmware then retries with smaller segments, which succeed. However, upon resume, the firmware again requests large segments, and the driver attempts to allocate memory accordingly. When allocation fails, the driver frees previously allocated segments but incorrectly handles the size of these segments during deallocation. Specifically, it attempts to free memory with a size larger than what was actually allocated, leading to a mismatch. This improper memory handling causes the kernel to detect a bad page state, resulting in a kernel crash (BUG: Bad page state). The root cause is a memory leak and improper freeing of DMA coherent memory segments during resume, which corrupts kernel memory management. This vulnerability can cause system instability and denial of service due to kernel crashes triggered by suspend/resume cycles on affected hardware configurations. No evidence currently suggests remote exploitation or privilege escalation, but the crash impacts system availability and reliability.
Potential Impact
For European organizations, the impact primarily concerns system availability and operational continuity. Systems running Linux kernels with the vulnerable ath12k driver on hardware using Qualcomm Atheros Wi-Fi chipsets may experience kernel crashes during suspend/resume cycles, leading to unexpected reboots or system downtime. This can disrupt business operations, especially in environments relying on Linux-based infrastructure such as servers, workstations, or embedded devices with wireless connectivity. Critical sectors like telecommunications, manufacturing, and public services that depend on stable wireless networking could face interruptions. Additionally, the kernel crash could potentially lead to data loss if unsaved work or transactions are interrupted. While this vulnerability does not appear to allow remote code execution or privilege escalation, the denial of service effect could be exploited by local attackers or malware to degrade system reliability. Organizations with strict uptime requirements or those using Linux in embedded or IoT devices with ath12k hardware are particularly at risk.
Mitigation Recommendations
To mitigate this vulnerability, organizations should: 1) Apply the latest Linux kernel patches that address CVE-2024-40979 as soon as they become available from their Linux distribution vendors or upstream kernel sources. 2) If immediate patching is not possible, consider disabling suspend/resume functionality or avoid using suspend states on affected systems to prevent triggering the crash. 3) Monitor system logs for kernel crash messages related to ath12k or DMA memory allocation failures to detect potential exploitation or instability early. 4) For critical systems, test kernel updates in a controlled environment to ensure stability before deployment. 5) Evaluate hardware configurations and consider alternative wireless chipsets or drivers if ath12k hardware is not essential. 6) Implement robust backup and recovery procedures to minimize data loss risk from unexpected crashes. 7) Engage with hardware and Linux vendors for guidance and support on firmware updates or driver patches that may complement kernel fixes.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain, Poland
CVE-2024-40979: Vulnerability in Linux Linux
Description
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix kernel crash during resume Currently during resume, QMI target memory is not properly handled, resulting in kernel crash in case DMA remap is not supported: BUG: Bad page state in process kworker/u16:54 pfn:36e80 page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80 page dumped because: nonzero _refcount Call Trace: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs ath12k_qmi_free_target_mem_chunk ath12k_qmi_msg_mem_request_cb The reason is: Once ath12k module is loaded, firmware sends memory request to host. In case DMA remap not supported, ath12k refuses the first request due to failure in allocating with large segment size: ath12k_pci 0000:04:00.0: qmi firmware request memory request ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144 ath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size ath12k_pci 0000:04:00.0: qmi delays mem_request 2 ath12k_pci 0000:04:00.0: qmi firmware request memory request Later firmware comes back with more but small segments and allocation succeeds: ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 Now ath12k is working. If suspend is triggered, firmware will be reloaded during resume. As same as before, firmware requests two large segments at first. In ath12k_qmi_msg_mem_request_cb() segment count and size are assigned: ab->qmi.mem_seg_count == 2 ab->qmi.target_mem[0].size == 7077888 ab->qmi.target_mem[1].size == 8454144 Then allocation failed like before and ath12k_qmi_free_target_mem_chunk() is called to free all allocated segments. Note the first segment is skipped because its v.addr is cleared due to allocation failure: chunk->v.addr = dma_alloc_coherent() Also note that this leaks that segment because it has not been freed. While freeing the second segment, a size of 8454144 is passed to dma_free_coherent(). However remember that this segment is allocated at the first time firmware is loaded, before suspend. So its real size is 524288, much smaller than 8454144. As a result kernel found we are freeing some memory which is in use and thus cras ---truncated---
AI-Powered Analysis
Technical Analysis
CVE-2024-40979 is a vulnerability in the Linux kernel's ath12k wireless driver, specifically affecting the handling of memory during system resume operations. The ath12k driver manages Qualcomm Atheros Wi-Fi chipsets. The issue arises during the resume phase after a system suspend, where the firmware requests memory segments from the host. Initially, the firmware requests large memory segments, but if DMA remapping is not supported, these allocations fail. The firmware then retries with smaller segments, which succeed. However, upon resume, the firmware again requests large segments, and the driver attempts to allocate memory accordingly. When allocation fails, the driver frees previously allocated segments but incorrectly handles the size of these segments during deallocation. Specifically, it attempts to free memory with a size larger than what was actually allocated, leading to a mismatch. This improper memory handling causes the kernel to detect a bad page state, resulting in a kernel crash (BUG: Bad page state). The root cause is a memory leak and improper freeing of DMA coherent memory segments during resume, which corrupts kernel memory management. This vulnerability can cause system instability and denial of service due to kernel crashes triggered by suspend/resume cycles on affected hardware configurations. No evidence currently suggests remote exploitation or privilege escalation, but the crash impacts system availability and reliability.
Potential Impact
For European organizations, the impact primarily concerns system availability and operational continuity. Systems running Linux kernels with the vulnerable ath12k driver on hardware using Qualcomm Atheros Wi-Fi chipsets may experience kernel crashes during suspend/resume cycles, leading to unexpected reboots or system downtime. This can disrupt business operations, especially in environments relying on Linux-based infrastructure such as servers, workstations, or embedded devices with wireless connectivity. Critical sectors like telecommunications, manufacturing, and public services that depend on stable wireless networking could face interruptions. Additionally, the kernel crash could potentially lead to data loss if unsaved work or transactions are interrupted. While this vulnerability does not appear to allow remote code execution or privilege escalation, the denial of service effect could be exploited by local attackers or malware to degrade system reliability. Organizations with strict uptime requirements or those using Linux in embedded or IoT devices with ath12k hardware are particularly at risk.
Mitigation Recommendations
To mitigate this vulnerability, organizations should: 1) Apply the latest Linux kernel patches that address CVE-2024-40979 as soon as they become available from their Linux distribution vendors or upstream kernel sources. 2) If immediate patching is not possible, consider disabling suspend/resume functionality or avoid using suspend states on affected systems to prevent triggering the crash. 3) Monitor system logs for kernel crash messages related to ath12k or DMA memory allocation failures to detect potential exploitation or instability early. 4) For critical systems, test kernel updates in a controlled environment to ensure stability before deployment. 5) Evaluate hardware configurations and consider alternative wireless chipsets or drivers if ath12k hardware is not essential. 6) Implement robust backup and recovery procedures to minimize data loss risk from unexpected crashes. 7) Engage with hardware and Linux vendors for guidance and support on firmware updates or driver patches that may complement kernel fixes.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-07-12T12:17:45.604Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9827c4522896dcbe157b
Added to database: 5/21/2025, 9:08:55 AM
Last enriched: 6/29/2025, 3:09:29 AM
Last updated: 8/1/2025, 4:41:58 AM
Views: 12
Related Threats
CVE-2025-9107: Cross Site Scripting in Portabilis i-Diario
MediumCVE-2025-9106: Cross Site Scripting in Portabilis i-Diario
MediumCVE-2025-9105: Cross Site Scripting in Portabilis i-Diario
MediumCVE-2025-9104: Cross Site Scripting in Portabilis i-Diario
MediumCVE-2025-9102: Improper Export of Android Application Components in 1&1 Mail & Media mail.com App
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.