IT Security 4 weeks ago

CVE-2024-40979: Linux ath12k Wi‑Fi Driver Kernel Crash on Resume – Impact, Detection & Fix

CVE-2024-40979 is a critical memory‑management flaw in the Linux ath12k Wi‑Fi driver that triggers a kernel panic during system resume on hardware without DMA remapping, leading to a complete denial‑of‑service. This article explains the vulnerability, affected systems, detection methods, and CVE-2024-40979 is a critical memory‑management flaw in the Linux ath12k Wi‑Fi driver that triggers a kernel panic during system resume on hardware without DMA remapping, leading to a…

FacebookXReddit

IT Security

Navigation: TECH OPS > IT Security > CVE Analysis

Executive Summary

CVE-2024-40979 is a critical memory management vulnerability in the Linux kernel’s ath12k Wi-Fi driver that causes immediate system crashes during suspend/resume cycles. The flaw affects systems using Qualcomm Atheros Wi-Fi hardware without DMA remapping support. When a system resumes from suspend, the driver attempts to free memory using incorrect size values, causing the kernel to free active memory pages and trigger a kernel panic. This results in a complete Denial of Service with no recovery possible without a reboot.

Who needs to act: System administrators managing Linux systems with ath12k Wi-Fi adapters, particularly on enterprise laptops and edge computing devices that use suspend/resume power management.

What Is CVE-2024-40979?

The Vulnerability at a Glance

CVE-2024-40979 is a kernel memory corruption bug in the ath12k wireless driver (drivers/net/wireless/ath/ath12k/qmi.c). The vulnerability manifests as a BUG: Bad page state kernel panic during system resume operations on hardware lacking DMA remapping capabilities.

The core issue: the driver maintains incorrect memory allocation size values, then uses these wrong values to free memory that was allocated at a different size. This causes the Direct Memory Access (DMA) subsystem to attempt freeing pages that are still actively in use by the kernel, triggering an immediate system crash.

Affected Component: Linux kernel ath12k wireless driver
Attack Vector: Local system power state transition (suspend/resume)
Impact: Denial of Service (system crash)
Exploitability: Highly predictable on vulnerable hardware

Why This Matters for Your Systems

Unlike many vulnerabilities that require active exploitation, CVE-2024-40979 triggers automatically whenever an affected system resumes from sleep. For organizations relying on laptop suspend/resume cycles for power management, this vulnerability can cause:

  • Unexpected system crashes during normal operations
  • Data loss if applications haven’t saved work before the crash
  • Reduced device availability in mobile workforce scenarios
  • Support burden from users experiencing unexplained reboots

The vulnerability is particularly problematic because:

  1. It’s automatic – no user interaction required beyond normal suspend/resume
  2. It’s reproducible – occurs consistently on affected hardware
  3. It’s unrecoverable – requires a full system restart
  4. It’s silent – users may not understand why their system crashed

How the Vulnerability Works

The Memory Allocation Problem

The ath12k driver communicates with Qualcomm wireless firmware through a Qualcomm Messaging Interface (QMI). During driver initialization, the firmware requests large memory allocations:

  • Type 1 segment: 7,077,888 bytes
  • Type 4 segment: 8,454,144 bytes

On systems without DMA remapping support, these large allocations fail. The driver handles this gracefully by deferring allocation until the firmware requests smaller chunks (524,288 bytes), which succeed. The system continues operating normally.

The problem: The driver stores the requested size values in its tracking variables, not the actual allocated size values.

What Happens During System Resume

When a system resumes from suspend:

  1. The kernel reloads the wireless firmware
  2. Firmware re-issues its initial large memory requests (7,077,888 and 8,454,144 bytes)
  3. The driver’s callback function ath12k_qmi_msg_mem_request_cb() updates its size tracking variables with these new large values
  4. The allocation attempt fails again (no DMA remapping support)
  5. The driver calls cleanup function ath12k_qmi_free_target_mem_chunk()

Why DMA Remapping Absence Triggers the Crash

DMA remapping (IOMMU support) allows the system to map physical memory addresses to virtual addresses for DMA operations. Without it, the driver must use physical memory directly.

When dma_alloc_coherent() fails on the first segment:

  • The allocation pointer (chunk->v.addr) is set to NULL
  • The cleanup function skips freeing this segment (correctly, since nothing was allocated)
  • But the size variable still contains the large requested value (8,454,144 bytes)

When attempting to free the second segment:

  • dma_free_coherent() is called with the new large size (8,454,144 bytes)
  • But only 524,288 bytes were actually allocated before suspend
  • The DMA free routine attempts to free 8,454,144 bytes of memory
  • This includes pages that are currently in use by the kernel
  • The kernel detects this corruption and triggers a panic

The Step-by-Step Failure Chain

1. System Resume
   ↓
2. Firmware Reload & Large Memory Requests
   ↓
3. Driver Updates Size Variables (now incorrect)
   ↓
4. dma_alloc_coherent() Fails (no DMA remapping)
   ↓
5. ath12k_qmi_free_target_mem_chunk() Called
   ↓
6. dma_free_coherent() Uses Wrong Size Value
   ↓
7. Attempts to Free Active Kernel Pages
   ↓
8. BUG: Bad page state Detected
   ↓
9. Kernel Panic (Denial of Service)

Who Is Affected

Vulnerable Linux Kernel Versions

Any Linux kernel version containing the ath12k driver prior to the upstream patch "wifi: ath12k: fix kernel crash during resume" is potentially vulnerable.

Check your kernel version:

uname -r

Common affected distributions include:

  • Ubuntu 22.04 LTS and later (with ath12k driver)
  • Fedora 36 and later
  • RHEL 9.x
  • Debian 12 (Bookworm)
  • Any distribution using Linux kernel 5.15+ with ath12k driver

Required Hardware Conditions

The vulnerability requires both conditions to be present:

  1. Qualcomm Atheros ath12k wireless adapter (or compatible)
  • Common in enterprise laptops
  • Found in some edge computing devices
  • Present in certain IoT gateways
  1. System hardware without DMA remapping (IOMMU) support
  • Older laptop chipsets
  • Some ARM-based systems
  • Certain embedded platforms

Check if your system has IOMMU support:

dmesg | grep -i iommu
# or
cat /proc/cmdline | grep -i iommu

If you see output like DMAR: IOMMU enabled, your system has DMA remapping and is not vulnerable.

Which Systems Are at Risk

High-risk environments:

  • Enterprise laptop fleets using suspend/resume for power management
  • Mobile workforce devices with ath12k adapters
  • Edge computing devices with Qualcomm wireless modules
  • IoT gateways using ath12k drivers

Lower-risk environments:

  • Desktop systems (rarely use suspend/resume)
  • Servers (typically don’t suspend)
  • Systems with modern Intel/AMD processors (usually have IOMMU)

Real-World Attack Scenarios

Local Denial of Service via Power Management

Scenario: A user closes their laptop lid, triggering suspend. When they reopen it, the system resumes.

What happens:

  1. Wireless firmware reloads during resume
  2. Driver receives large memory allocation requests
  3. Allocation fails on hardware without DMA remapping
  4. Driver attempts cleanup with incorrect size values
  5. Kernel panic occurs
  6. System becomes unresponsive

Business impact:

  • User loses unsaved work
  • Productivity interrupted
  • Support ticket generated
  • Potential data corruption if databases were active

Malicious scenario: An attacker with local access could:

  1. Trigger suspend/resume cycles programmatically
  2. Cause repeated system crashes
  3. Deny service to legitimate users
  4. Potentially corrupt system state

Predictability and Exploitability

This vulnerability is highly predictable because:

  • It triggers on every suspend/resume cycle on vulnerable hardware
  • No special conditions or timing required
  • No user interaction needed beyond normal power management
  • Occurs consistently and reliably

CVSS Considerations:

  • Attack Vector: Local
  • Attack Complexity: Low
  • Privileges Required: None (user can trigger suspend)
  • User Interaction: None
  • Scope: Unchanged
  • Confidentiality Impact: None
  • Integrity Impact: High (memory corruption)
  • Availability Impact: High (system crash)

Detecting CVE-2024-40979 on Your Systems

Kernel Log Indicators

Check your system logs for these telltale messages:

Primary indicator:

ath12k_pci 0000:XX:XX.X: qmi dma allocation failed (XXXXXXX B type 1), will try later with small size

Crash indicator:

BUG: Bad page state in process kworker/...

Memory corruption indicator:

page:ffffea0001234567 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12345
flags: 0x0()

Call Stack Signatures

When the crash occurs, the kernel log will show a call stack. Look for these function names in sequence:

bad_page()
free_page_is_bad_report()
dma_direct_free()
dma_free_attrs()
ath12k_qmi_free_target_mem_chunk()
ath12k_qmi_msg_mem_request_cb()

How to Check Your Logs

On systemd systems:

# Check recent kernel messages
journalctl -k -n 100 | grep -E "ath12k|Bad page state|dma_free"
# Check for specific error patterns
journalctl -k | grep "qmi dma allocation failed"
# Export full log for analysis
journalctl -k > kernel_log.txt

On traditional syslog systems:

# Check kernel ring buffer
dmesg | grep -E "ath12k|Bad page state"
# Check system log
grep -E "ath12k|Bad page state" /var/log/kern.log
# Check for allocation failures
grep "qmi dma allocation failed" /var/log/syslog

Create a detection script:

#!/bin/bash
# Check for CVE-2024-40979 indicators
echo "=== Checking for ath12k driver ==="
lsmod | grep ath12k
echo "=== Checking for DMA allocation failures ==="
dmesg | grep "qmi dma allocation failed"
echo "=== Checking for kernel crashes ==="
dmesg | grep "BUG: Bad page state"
echo "=== Checking kernel version ==="
uname -r
echo "=== Checking for IOMMU support ==="
dmesg | grep -i iommu

How to Fix It

Immediate Mitigation Steps

Short-term workarounds (not recommended for production):

  1. Disable suspend/resume:
   # Disable sleep states
   sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Note: This reduces power efficiency but prevents crashes

  1. Disable ath12k driver (if alternative wireless available):
   # Blacklist the driver
   echo "blacklist ath12k" | sudo tee /etc/modprobe.d/ath12k-blacklist.conf
   sudo update-initramfs -u

Note: This disables wireless functionality

  1. Reduce suspend frequency:
  • Adjust power management settings to minimize suspend/resume cycles
  • Increase idle timeout before suspend

These are temporary measures only. The proper fix is a kernel update.

Applying the Kernel Patch

For Ubuntu/Debian systems:

# Update package lists
sudo apt update
# Upgrade kernel
sudo apt upgrade linux-image-generic
# Reboot to new kernel
sudo reboot

For Fedora/RHEL systems:

# Update kernel
sudo dnf upgrade kernel
# Reboot to new kernel
sudo reboot

For manual kernel compilation:

  1. Download patched kernel source
  2. Apply patch: patch -p1 < ath12k-resume-fix.patch
  3. Configure and compile
  4. Install and reboot

Verify the patch is applied:

# Check if fix is in kernel source
grep -r "fix kernel crash during resume" /usr/src/linux*/
# Check kernel version includes fix
uname -r

Verification After Update

Confirm the fix:

# 1. Verify new kernel is running
uname -r
# 2. Verify ath12k driver is loaded
lsmod | grep ath12k
# 3. Test suspend/resume cycle
sudo systemctl suspend
# (Wait for system to resume)
# 4. Check for crash indicators
dmesg | tail -50 | grep -E "ath12k|Bad page state"
# 5. Verify no errors in logs
journalctl -k -n 50 | grep -E "error|crash|panic"

If verification succeeds:

  • No “Bad page state” messages
  • No “qmi dma allocation failed” messages
  • System resumes cleanly
  • Wireless connectivity maintained

Technical Deep Dive

Memory Allocation Failure Sequence

The vulnerability stems from a mismatch between requested and allocated memory sizes:

Before suspend (initialization):

Firmware Request: 8,454,144 bytes (Type 4)
  ↓
dma_alloc_coherent() fails (no DMA remapping)
  ↓
Driver retries with smaller size: 524,288 bytes
  ↓
dma_alloc_coherent() succeeds
  ↓
Actual allocation: 524,288 bytes
Stored size variable: 524,288 bytes (correct)

During resume:

Firmware Request: 8,454,144 bytes (Type 4)
  ↓
Driver updates size variable: 8,454,144 bytes (INCORRECT)
  ↓
dma_alloc_coherent() fails (no DMA remapping)
  ↓
Cleanup called with size: 8,454,144 bytes
  ↓
But actual allocation is still: 524,288 bytes
  ↓
MISMATCH CAUSES CRASH

DMA Free Corruption Mechanism

The dma_free_coherent() function uses the provided size to determine how many pages to free:

// Pseudocode of the vulnerability
void ath12k_qmi_free_target_mem_chunk(struct ath12k_base *ab) {
    for (i = 0; i < ab->qmi.mem_seg_count; i++) {
        struct target_mem_chunk *chunk = &ab->qmi.target_mem[i];
        if (chunk->v.addr) {
            // BUG: Uses ab->qmi.target_mem[i].size which was updated
            // during resume, not the actual allocation size
            dma_free_coherent(ab->dev, 
                            chunk->size,  // WRONG SIZE!
                            chunk->v.addr,
                            chunk->paddr);
        }
    }
}

When dma_free_coherent() receives an oversized size value:

  1. It calculates pages to free: pages = size / PAGE_SIZE
  2. It attempts to free more pages than were allocated
  3. It tries to free pages that are in use by other kernel subsystems
  4. The page allocator detects the corruption
  5. Kernel panic is triggered

Why Suspend/Resume Triggers the Bug

The bug only manifests during suspend/resume because:

  1. Initialization: Firmware requests large sizes, allocation fails, driver retries with smaller sizes. Size variables are set correctly to the smaller value.

  2. Normal operation: System uses the smaller allocated memory. No crash occurs.

  3. Suspend: Wireless device is powered down. Memory remains allocated.

  4. Resume: Firmware reloads and re-issues initial large memory requests. The callback function updates size variables to the large values. Allocation fails again. Cleanup is called with the new large size values, causing the mismatch.

The vulnerability requires this specific sequence: successful small allocation followed by resume with large allocation request.

Severity Assessment

Impact on System Availability

System availability impact timeline showing crash occurrence during resume and recovery time.
System availability impact timeline showing crash occurrence during resume and recovery time.

Immediate impact:

  • System becomes completely unresponsive
  • All running applications are terminated
  • Unsaved data is lost
  • Network connectivity is severed

Recovery time:

  • Manual reboot required (no automatic recovery)
  • Typical recovery: 2-5 minutes
  • Potential data corruption if databases were active

Cumulative impact:

  • Each suspend/resume cycle risks a crash
  • Users may avoid suspend/resume, reducing power efficiency
  • Increased support costs from crash reports

Scope of the Threat

Affected user base:

  • Estimated millions of Linux laptop users with ath12k adapters
  • Enterprise deployments with Qualcomm wireless hardware
  • IoT/edge computing deployments using ath12k drivers

Geographic/industry distribution:

  • Affects all Linux distributions with ath12k driver
  • Impacts organizations using Qualcomm wireless in Linux devices
  • Particularly affects BYOD programs with Linux laptops

Temporal scope:

  • Affects all kernel versions with ath12k driver prior to patch
  • Vulnerability exists from driver introduction until patch release
  • Affects systems that haven’t applied kernel updates

Why This Is a High-Priority Fix

Severity factors:

  1. Automatic trigger: No special conditions required; occurs on normal suspend/resume
  2. Complete DoS: System becomes completely unusable; no partial functionality
  3. Unrecoverable: Requires manual reboot; no automatic recovery
  4. Data loss: Unsaved work is lost; potential database corruption
  5. Predictable: Occurs consistently on vulnerable hardware
  6. Wide impact: Affects all users of affected hardware/kernel combinations

Risk rating: HIGH

  • CVSS Vector: AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
  • CVSS Score: Estimated 7.1 (High)
  • Recommendation: Apply patch immediately to all affected systems

Frequently Asked Questions

What triggers CVE-2024-40979?

The vulnerability is triggered when a system using the ath12k Wi-Fi driver resumes from suspend on hardware without DMA remapping support. The resume process causes the driver to attempt freeing memory with incorrect size values.

Specifically:

  • System must have ath12k wireless adapter
  • System must lack DMA remapping (IOMMU) support
  • System must perform suspend/resume cycle
  • All three conditions must be present

Why does the kernel crash during resume?

During resume, the driver receives new large memory allocation requests from firmware and updates its size tracking variables. When allocation fails (due to lack of DMA remapping), the cleanup process uses these new larger values to free memory that was actually allocated at a much smaller size before suspend. This causes the DMA free routines to attempt freeing active kernel pages, triggering a kernel panic.

The crash occurs because:

  1. Size variable is updated to large value (8,454,144 bytes)
  2. Allocation fails
  3. Cleanup uses the large value
  4. But only small amount was actually allocated (524,288 bytes)
  5. Kernel attempts to free pages that are in use
  6. Page allocator detects corruption and panics

Does this vulnerability allow remote code execution?

No. CVE-2024-40979 results in an immediate kernel crash and Denial of Service. There is no documented code execution mechanism associated with this vulnerability. The crash occurs before any code execution could be achieved.

The vulnerability is limited to:

  • Memory corruption (freeing wrong pages)
  • Denial of Service (kernel panic)
  • Data loss (unsaved work)

Which Linux distributions are affected?

Any Linux distribution using the ath12k Wi-Fi driver on hardware without DMA remapping support is potentially affected. This includes:

  • Ubuntu: 22.04 LTS and later (with ath12k)
  • Fedora: 36 and later
  • RHEL: 9.x
  • Debian: 12 (Bookworm)
  • Arch Linux: Current releases with ath12k
  • openSUSE: Leap 15.4 and later

Check your distribution’s kernel version against the patch release date.

Can I work around this without updating my kernel?

The primary mitigation is a kernel update. As temporary workarounds, you can:

  1. Disable suspend/resume:
   sudo systemctl mask sleep.target suspend.target

Reduces power efficiency but prevents crashes

  1. Disable ath12k driver:
   echo "blacklist ath12k" | sudo tee /etc/modprobe.d/ath12k-blacklist.conf

Disables wireless functionality

  1. Avoid suspend cycles:
  • Keep system powered on
  • Use hibernate instead of suspend (if available)
  • Adjust power settings to prevent automatic suspend

However, these are not reliable long-term solutions. A kernel update is the proper fix.

How do I know if my hardware has DMA remapping support?

Check your system logs for IOMMU (DMA remapping) messages:

# Check for IOMMU support
dmesg | grep -i iommu
# Check kernel command line
cat /proc/cmdline | grep -i iommu
# Check for DMAR (Intel IOMMU)
dmesg | grep -i dmar

If you see output like:

  • DMAR: IOMMU enabled
  • AMD-Vi: IOMMU enabled
  • iommu: Default domain type: Translated

Your system has DMA remapping and is not vulnerable.

If you see:

  • qmi dma allocation failed messages
  • No IOMMU-related messages
  • DMAR: IOMMU disabled

Your system lacks DMA remapping and is vulnerable.

What is the CVSS score for this vulnerability?

The specific CVSS score is not provided in the official vulnerability documentation, but based on the characteristics:

Estimated CVSS v3.1 Score: 7.1 (High)

  • Attack Vector: Local (AV:L)
  • Attack Complexity: Low (AC:L)
  • Privileges Required: None (PR:N)
  • User Interaction: None (UI:N)
  • Scope: Unchanged (S:U)
  • Confidentiality: None (C:N)
  • Integrity: High (I:H) – memory corruption
  • Availability: High (A:H) – system crash

This is classified as a high-impact Denial of Service vulnerability affecting system availability and data integrity.

Will this affect my system if I don’t use suspend/resume?

No. The vulnerability is specifically triggered during suspend/resume cycles. Systems that remain powered on continuously are not affected.

If your system:

  • Never suspends (always powered on)
  • Uses hibernation instead of suspend
  • Doesn’t have ath12k wireless adapter
  • Has DMA remapping support

Then you are not vulnerable to CVE-2024-40979.

References

Official CVE Information:

  • CVE Identifier: CVE-2024-40979
  • CVE Description: Linux kernel ath12k driver memory corruption during resume
  • Vulnerability Type: CWE-416 (Use After Free) / CWE-415 (Double Free)

Linux Kernel Patch:

  • Patch Title: wifi: ath12k: fix kernel crash during resume
  • Affected File: drivers/net/wireless/ath/ath12k/qmi.c
  • Patch Type: Memory management fix in QMI callback handler

Related Resources:

  • Linux Kernel Security: https://www.kernel.org/
  • Qualcomm Atheros Driver Documentation
  • DMA Remapping (IOMMU) Documentation
  • Linux Wireless Driver Documentation

Monitoring and Detection:

  • Kernel log analysis tools
  • System monitoring solutions
  • Security information and event management (SIEM) systems

Article Last Updated: 2024
Severity Level: HIGH
Recommended Action: Apply kernel patch immediately to all affected systems

← Back to IT Security