CVE-2024-40979: Linux ath12k resume crash fixed in 6.9.7 / 6.10 RC1

A subtle memory-management bug in the Linux kernel’s ath12k Wi‑Fi driver — tracked as CVE-2024-40979 — could cause a complete kernel crash when a Qualcomm Atheros-based wireless device resumes from suspend, producing a local denial‑of‑service condition for affected hosts. The fault lies in how the driver frees firmware-backed DMA segments during resume: an incorrect size is passed to dma_free_coherent(), which can lead to freeing memory that’s still in use and triggering an immediate kernel oops. Patches have landed in the upstream kernel (fixed in 6.9.7 and merged into the 6.10 release candidate) and distributions are rolling updates; system owners should prioritize kernel updates or backport the upstream changes to remove a reliable crash primitive.

Background / Overview​

The ath12k driver implements support for Qualcomm Atheros’ modern Wi‑Fi chips (WCN7850, QCN9274 and related families). These SoCs use QMI-mediated memory management and firmware regions that the kernel driver allocates and later frees across driver lifecycle events like firmware load, suspend, resume, and module removal. CVE-2024-40979 was assigned after maintainers discovered a scenario where the driver’s bookkeeping for segment sizes diverged from reality, so the driver attempted to free a larger region than originally allocated — a mismatch that can cause the kernel to crash at resume time.
This vulnerability is primarily an availability impact (denial of service) rather than a confidentiality or integrity compromise: an attacker with local access — or a benign sequence of system events — can trigger a kernel crash and cause host unavailability until the kernel is restarted. Distribution security pages and upstream advisories classify the issue as moderate to medium severity, but the operational consequences for servers, laptops or embedded devices that rely on Wi‑Fi connectivity can be significant.

---

What exactly went wrong: technical root cause​

How ath12k manages firmware DMA memory​

To communicate with the firmware and handle data buffers efficiently, ath12k allocates contiguous DMA-capable memory regions using dma_alloc_coherent() and later releases them with dma_free_coherent(). These allocations are split into segments managed inside a target_mem_chunk structure; the driver must reliably remember each segment’s allocated size to free the exact memory it originally reserved. Mistakes in this bookkeeping make the driver vulnerable to double‑free, invalid-free, or freeing larger/smaller regions than were allocated.

The size mismatch and the resume path​

The crash scenario reported by the kernel maintainers arises during resume from suspend. The driver assumes a certain size when freeing a segment at resume time, but that size no longer matches the actual size allocated earlier when the firmware was first loaded. In at least one affected code path, a value of 8,454,144 bytes (an inflated size) was passed to dma_free_coherent() while the original allocation size was 524,288 bytes — effectively telling the kernel to free a block of memory that crosses into regions still in use. The kernel’s memory safety checks detect the invalid free and crash to avoid silent corruption.

The fix: persist the real segment size and reuse buffers​

Upstream patches address the problem by adding a stored previous-size field to the target_mem_chunk structure and using that prev_size when freeing segments, ensuring the same size used for allocation is used for deallocation. The patch also applies QMI memory reuse techniques akin to those already present in the ath11k driver and reuses the M3 buffer where appropriate, preventing the mismatch entirely. The kernel CVE team notes the change was small and surgical but closes a reliable crash primitive.

---

Timeline and patch status​

• The upstream fix was authored and reviewed during the kernel development cycle and the Linux kernel CVE team publicly assigned CVE-2024-40979 to the issue. The fix was applied to the relevant driver files (drivers/net/wireless/ath/ath12k/core.c, qmi.c and qmi.h).
• The corrective commits appear in upstream stable trees — fixed in Linux kernel 6.9.7 (commit bb50a4e7...) and included in 6.10-rc1 (commit 303c0178...). Distribution kernels may backport these commits to their maintained kernel branches or include fixes in downstream package updates.
• Vendor advisories (SUSE, Amazon ALAS, and other distribution trackers) have cataloged the CVE and marked it resolved with updated kernels; however, scoring and the reported CVSS vary between sources (some report a CVSS around 4.4 while others record a 5.5), reflecting differing assessment details such as privileges required and attack complexity. Administrators should consult their distribution’s security tracker for precise package versions that contain the backport.

---

Who’s affected and how to prioritize​

• Affected component: Linux kernel ath12k driver, the Qualcomm Atheros Wi‑Fi 7/6 driver common in many laptops and some embedded devices that use WCN78xx/WCN99xx family chips.
• Attack vector: local — an adversary or a script that can exercise resume behavior (suspend/resume) on a target host. The bug is not a remote network exploit by default; it requires local code execution or physical access to trigger a resume sequence. This reduces remote exploitability but still leaves important attack surfaces: multi‑user systems, shared machines, or endpoint agents that can trigger suspend/resume cycles.
• Impact: Availability / Denial of Service — immediate kernel crash (panic/oops) leading to service interruption. For servers, network appliances, or endpoints that cannot tolerate reboots, this is a high operational risk even if the CVSS is described as medium.

Given these facts, organizations should treat the issue as priority for systems where Wi‑Fi availability matters or where a forced reboot could have high operational impact (for example: kiosk systems, industrial gateways, telepresence endpoints, or laptops used for remote work that host critical sessions).

---

Detection, exploitation evidence and real‑world risk​

• Public exploit evidence: at the time of writing there is no widely published proof‑of‑concept or evidence of active exploitation in the wild tied specifically to CVE-2024-40979. Threat feeds and CVE trackers indicate patches are available and recommend updates, but they do not show POC code or abuse reports. That said, a trivial local crash is an attractive stability-exploitable primitive for attackers who already have local access. Lack of public exploits does not imply safe exposure.
• Ease of exploitation: the vulnerability requires the target to run the affected kernel and for a resume action to exercise the mismatched free. A local adversary who can run unprivileged or privileged code may be able to trigger the crash; details from vendor scoring indicate the privilege requirement may vary depending on environment. Some sources mark the privileges required as low to high depending on their analysis; operators should examine their threat model accordingly.
• Operational impact: repeated crashes can be used as a stability denial-of-service (sustained while the attacker repeatedly triggers resume cycles), or a single crash can create a persistent outage until a reboot or kernel update is applied. This is particularly consequential for headless or remotely managed systems where physical access is not available.

---

Recommended remediation and mitigation steps​

Administrators should follow a layered, risk‑oriented approach:

• Update kernels first:
• Install distribution-provided kernel updates that include the upstream fixes (look for the kernel package that contains the 6.9.7 stable backport or the equivalent vendor backport).
• Reboot hosts after installing the kernel update to ensure the patched driver is loaded. Upstream notes and stable‑tree commit messages confirm fixes landed in 6.9.7 and 6.10-rc1.
• If immediate kernel updates are impossible:
• Request vendor-specific backports or temporary hotpatches from your distribution or hardware vendor.
• Consider unloading the ath12k module if Wi‑Fi is non-essential on a host (modprobe -r ath12k) and use wired networking where feasible. Be cautious: unloading a module on a running system can have side effects and may not be possible if the driver is in use.
• Tighten local access controls:
• Restrict local untrusted user access to systems that host sensitive services.
• Harden remote management interfaces so attackers cannot trigger suspend/resume cycles remotely (for example: disable remote scripts that can put a host into suspend on behalf of untrusted users).
• Monitor and test:
• Validate updates in a test environment that matches production hardware (especially laptops or embedded boards using the WCN78xx family) before mass rollout.
• Use existing host telemetry or crash logging to detect kernel oopses (look for ath12k-related call traces in dmesg/syslog). The upstream advisory describes the kernel trace patterns that arise during the faulty free.
• Communicate with vendors:
• If you operate OEM images or vendor kernels (for example, custom kernels on appliances or UEFI-locked devices), contact the vendor for a coordinated fix or guidance on backports and mitigations. Distribution advisories differ in how they score or backport fixes; vendor guidance should be authoritative for your installed image.

---

How to verify a host is patched​

• Check kernel version: systems running a kernel equal to or newer than the stable release that includes the fix (or vendor kernels explicitly mentioning the CVE in their changelog) are considered patched. The upstream stable commit notes list 6.9.7 as a fixed release and 6.10-rc1 as carrying the change; distribution backporting will vary.
• Inspect driver source/build: for environments that build kernels from source, confirm the presence of the commit that adds prev_size and the modified qmi/target memory handling in drivers/net/wireless/ath/ath12k/{core.c,qmi.c,qmi.h}. The commit messages are brief and identify the added prev_size field and the reuse of buffers.
• Watch for kernel oops signatures: unpatched systems experiencing the bug will show call traces linked to dma_free_coherent() around ath12k_qmi_free_target_mem_chunk() and unusual free sizes referenced in the logs. If you’re seeing reproducible resume crashes that mention ath12k and dma_free_coherent in the stack, prioritize a patch.

---

Distribution and vendor status: what’s been said publicly​

Major trackers and vendors have recorded the CVE and issued guidance:

• The Linux kernel CVE announcement lists the affected files, the reasoning for the fix, and the specific commits that remedied the defect. It explicitly assigns CVE-2024-40979 to the ath12k resume crash and directs operators to update to stable kernels or apply the specific commits if needed.
• Distribution security summaries show inconsistent scoring but consistent remediation: SUSE marks the issue resolved and rates Availability as impacted, while Amazon’s ALAS tracker lists the CVSS as lower but still highlights the denial‑of‑service nature and recommends updates where relevant. These variations reflect different scoring methodologies but do not change the operational guidance: update kernels.
• Public vulnerability aggregators (cvefeed.io, Feedly CVE summaries and other trackers) echo the upstream fix, include patch references and classify the issue as a memory-management bug (CWE-401 / missing release of memory), again recommending kernel updates for remediation.

Internally, vendor conversations about ath12k, Azure Linux attestations, and how Microsoft scopes open-source vulnerability notices have been a persistent theme for similar ath* family CVEs; the take-away for operators is to treat vendor product attestations as authoritative inventory statements for that vendor’s images and to query each vendor for product-specific impact and patched package versions.

---

Assessing the residual risk after patching​

Applying the upstream fix removes the specific invalid-free crash path fixed by CVE-2024-40979, but two wider operational realities remain:

• Kernel driver code is complex and hardware-specific. Similar memory-management mistakes in other parts of the driver (or in other drivers) can produce related crash primitives. Ongoing QA, fuzz testing, and regression checks remain critical. Upstream maintainers intentionally constrained this change, but continuous vigilance is necessary.
• Distribution coverage and backport practices differ. Some enterprise distributions backport fixes into older kernel releases and label them as patched; others require an upgrade to a newer baseline kernel. For managed environments, ensure your patching plan maps vendor advisories to your installed kernel packages rather than relying solely on upstream version numbers.

Finally, because the issue requires local triggering, reducing attacker-controlled local code execution remains a strong mitigation: limit untrusted code execution, enforce least privilege, and isolate user workloads to minimize the blast radius of an attacker able to reboot or suspend a host.

---

Practical checklist for WindowsForum readers / administrators​

• Immediate actions:
• Identify hosts that run ath12k-supported Qualcomm Atheros Wi‑Fi chips.
• Check kernel versions and vendor package changelogs for CVE-2024-40979 or the upstream commit IDs.
• Schedule and test kernel updates; reboot after patching.
• If patching is delayed:
• Where feasible, switch to wired networking or unload ath12k on noncritical systems.
• Restrict local logins and services that could trigger suspend/resume cycles under attacker control.
• Monitor boot and kernel logs for ath12k/dma_free_coherent call traces.
• Long term:
• Incorporate kernel module auditing into change control and vulnerability management.
• Maintain vendor contacts for embedded or OEM systems where kernel updates are slower.
• Run periodic regression tests that include suspend/resume cycles on representative hardware.

---

Final analysis: why this matters and how to think about it​

CVE-2024-40979 is an exemplar of a common, high‑value class of kernel bugs: memory-management mismatches in device drivers. These bugs are rarely subtle to fix (often a small change like remembering the original allocation size), but they have outsized impact because they run in kernel context and can immediately terminate host availability. For operations teams, the immediate question is not whether the patch is big or risky — it isn’t — but whether the patch is installed across the fleet and whether systems that cannot be easily rebooted are defensively configured.
The technical fix is clean and straightforward upstream; the practical work is organizational: ensuring the patch propagates through vendor kernels, validating fixes on real hardware, and adjusting operational playbooks to prevent local attackers from weaponizing device-driver bugs. The upstream commit history and distribution advisories confirm the fix and provide the authoritative path to remediation.
In short: treat CVE-2024-40979 as a priority for systems where Wi‑Fi stability matters, update kernels promptly, and harden local-access controls to reduce the opportunity for an attacker to trigger a suspend/resume crash. The bug’s technical footprint is small, but the availability impact can be significant in the wrong context — and that is exactly the kind of vulnerability defenders should eliminate as quickly as engineering processes allow.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center