CVE-2026-31552: Linux Kernel WiFi DoS Vulnerability

CVE-2026-31552 Overview

CVE-2026-31552 is an Infinite Loop vulnerability in the Linux kernel's wlcore WiFi driver that can lead to a CPU soft lockup and denial of service condition. The vulnerability exists in the wlcore_tx_work_locked() function where an incorrect error code return value from wl1271_prepare_tx_frame() causes a tight infinite retry loop when memory allocation fails during SKB headroom expansion.

The flaw was introduced after upstream commit e75665dd0968 ("wifi: wlcore: ensure skb headroom before skb_push"), which modified wl1271_tx_allocate() to return -EAGAIN when pskb_expand_head() fails. However, -EAGAIN is interpreted by wlcore_tx_work_locked() as an indication that the aggregation buffer is full, triggering an immediate retry that creates an infinite loop while holding wl->mutex.

Critical Impact
This vulnerability enables remote attackers to cause a complete denial of service through CPU soft lockup on systems using the wlcore WiFi driver, affecting network availability without requiring authentication.

Affected Products

Linux Kernel versions prior to the security fix
Linux Kernel 6.19
Linux Kernel 7.0 Release Candidates (rc1 through rc7)

Discovery Timeline

April 24, 2026 - CVE-2026-31552 published to NVD
April 27, 2026 - Last updated in NVD database

Technical Details for CVE-2026-31552

Vulnerability Analysis

The vulnerability is a classic case of error code misinterpretation leading to an infinite loop. When the wlcore driver attempts to transmit a frame and encounters insufficient headroom in the socket buffer (SKB), it calls pskb_expand_head() to allocate additional memory. If this allocation fails (which can occur under memory pressure), wl1271_tx_allocate() returns -EAGAIN.

The problem arises in wlcore_tx_work_locked(), which interprets -EAGAIN as a signal that the aggregation buffer is full and needs to be flushed. The function then flushes the buffer, places the SKB back at the head of the queue, and immediately retries transmission—all while holding wl->mutex. Since memory allocation continues to fail with GFP_ATOMIC (which cannot sleep or wait for memory), the retry loop never terminates, causing a CPU soft lockup.

Root Cause

The root cause is semantic confusion in error code handling. The -EAGAIN return value has an overloaded meaning in this code path—it can indicate either "aggregation buffer full, retry later" or "memory allocation failed." The fix correctly returns -ENOMEM for memory allocation failures, allowing the packet to be dropped and the loop to terminate normally.

Attack Vector

An attacker could potentially exploit this vulnerability by creating conditions that trigger memory exhaustion or high memory pressure on a target system with a wlcore WiFi adapter. This could be achieved through network-based attacks that cause the system to process large numbers of packets, depleting available memory for SKB headroom expansion.

The attack is particularly dangerous because:

It does not require authentication
It operates over the network
The infinite loop runs while holding a mutex, potentially blocking other WiFi operations
The soft lockup can render the system unresponsive

Since no verified code examples are available for this vulnerability, the technical mechanism can be described as follows: When wl1271_prepare_tx_frame() calls wl1271_tx_allocate() and pskb_expand_head() fails due to memory constraints, the function returns -EAGAIN. The calling function wlcore_tx_work_locked() misinterprets this as an aggregation buffer condition and enters a tight retry loop. The fix changes the return value to -ENOMEM, which causes the packet to be dropped instead of retried indefinitely. See the Linux Kernel Commit Fix for implementation details.

Detection Methods for CVE-2026-31552

Indicators of Compromise

Unexplained CPU soft lockup messages in kernel logs (dmesg/journalctl)
System unresponsiveness associated with WiFi activity on wlcore-based adapters
Kernel watchdog triggers or NMI watchdog alerts referencing wlcore_tx_work_locked
High CPU utilization on a single core without corresponding user-space process activity

Detection Strategies

Monitor kernel logs for soft lockup warnings containing "wlcore" or "wl1271" references
Implement watchdog monitoring to detect systems becoming unresponsive during network operations
Use kernel tracing (ftrace) to monitor wlcore_tx_work_locked() execution patterns on systems with wlcore hardware
Deploy endpoint detection that can identify anomalous kernel thread behavior and CPU saturation patterns

Monitoring Recommendations

Configure system logging to capture kernel warnings and soft lockup events
Set up alerts for repeated memory allocation failures in the network subsystem
Monitor for extended mutex hold times in kernel WiFi driver code paths
Implement network traffic analysis to detect potential denial of service attack patterns targeting WiFi systems

How to Mitigate CVE-2026-31552

Immediate Actions Required

Update to a patched Linux kernel version that includes the wlcore driver fix
On systems that cannot be immediately updated, consider disabling the wlcore WiFi driver if alternative network connectivity is available
Monitor affected systems for signs of exploitation while awaiting patch deployment
Implement resource limits and memory pressure monitoring to reduce exploitation likelihood

Patch Information

The Linux kernel maintainers have released patches across multiple stable branches. The fix modifies wl1271_tx_allocate() to return -ENOMEM instead of -EAGAIN when pskb_expand_head() fails, ensuring proper error handling and loop termination.

Official patches are available from the following kernel commits:

Workarounds

Blacklist the wlcore kernel module (modprobe.blacklist=wlcore) if the hardware is not required
Use alternative WiFi hardware with different drivers until the system can be patched
Implement network segmentation to limit exposure of vulnerable systems to untrusted traffic
Configure memory resource limits to reduce the likelihood of triggering the vulnerable code path

bash

# Temporary workaround: Blacklist wlcore module
echo "blacklist wlcore" >> /etc/modprobe.d/wlcore-blacklist.conf
echo "blacklist wl12xx" >> /etc/modprobe.d/wlcore-blacklist.conf
echo "blacklist wl18xx" >> /etc/modprobe.d/wlcore-blacklist.conf

# Unload module if currently loaded
modprobe -r wl18xx wl12xx wlcore

# Update initramfs to persist changes
update-initramfs -u