CVE-2026-31552

What it actually does

A flaw in the Linux kernel wlcore Wi-Fi driver can cause an infinite retry loop during packet transmission when skb headroom expansion fails under atomic memory-allocation conditions. The driver incorrectly treats an out-of-memory condition as a temporary aggregation-buffer-full condition, requeues the same packet, flushes, and immediately retries while holding wl->mutex. This can pin CPU execution in the kernel, trigger a CPU soft lockup, and degrade or deny system availability. The issue affects systems using the wlcore family of Wi-Fi drivers, commonly associated with TI WiLink wl12xx/wl18xx-class devices.

Why it matters to the business

Systems that rely on affected Linux kernels and wlcore-based Wi-Fi connectivity may become unresponsive or suffer severe performance degradation, potentially disrupting embedded devices, gateways, industrial systems, mobile Linux platforms, or appliances using those wireless chipsets. Although there is currently no known public exploit maturity, no CISA KEV listing, no ransomware association, and EPSS is low and flat at 0.0050, the vulnerability has been public for 110 days and should be remediated during normal kernel maintenance, with higher priority for internet- or untrusted-network-facing wireless devices.

How an attack unfolds

An attacker needs a way to cause the affected host to transmit traffic through a vulnerable wlcore Wi-Fi interface while the kernel encounters insufficient memory/headroom expansion during transmit preparation. When wl1271_prepare_tx_frame() encounters pskb_expand_head() failure, the vulnerable code returns -EAGAIN. wlcore_tx_work_locked() interprets that value as a full aggregation buffer rather than a hard allocation failure, flushes the buffer, places the same skb back at the head of the queue, and retries immediately. Because this occurs in a tight loop while holding the wlcore mutex and using GFP_ATOMIC allocation context, the same packet can be retried indefinitely. The result is CPU soft lockup and denial of service rather than code execution or data compromise.

How to fix it

Upgrade to a vendor-supported Linux kernel release that includes the wlcore fix changing the out-of-memory return path from -EAGAIN to -ENOMEM so the packet is dropped and the retry loop terminates. No exact fixed package versions were provided in the input, so use the relevant Linux distribution, device vendor, or kernel-stable advisory for the patched kernel version. After installing the patched kernel, reboot into it and ensure affected wlcore modules are rebuilt or replaced. If immediate patching is not possible, mitigate by disabling or blacklisting wlcore-related modules where operationally feasible, avoiding use of affected TI WiLink-based Wi-Fi hardware, limiting exposure to untrusted wireless/network traffic, and monitoring for memory pressure and kernel soft lockup events.

How to confirm the fix worked

Confirm exposure by checking whether the system runs an affected Linux kernel and has wlcore-related modules loaded or available, such as wlcore, wlcore_sdio, wl12xx, or wl18xx. Confirm remediation by verifying the running kernel version after reboot, reviewing distribution or vendor changelogs for the wlcore fix, or inspecting patched source to ensure wl1271_tx_allocate()/wl1271_prepare_tx_frame() returns -ENOMEM rather than -EAGAIN when pskb_expand_head() fails. Validate operationally by confirming there are no recurring kernel soft lockup messages involving wlcore_tx_work_locked(), wl1271_prepare_tx_frame(), wl1271_tx_allocate(), or pskb_expand_head() after the update.

Typical attack path

1. Identify or reach a Linux system using an affected kernel with the wlcore Wi-Fi driver active.
2. Generate or induce traffic that causes the target to transmit packets over the affected Wi-Fi interface.
3. Trigger a transmit path where skb headroom expansion fails, typically under memory pressure or constrained atomic allocation conditions.
4. Cause wl1271_prepare_tx_frame() to return -EAGAIN for the failed allocation.
5. Cause wlcore_tx_work_locked() to mis-handle the failure as an aggregation-buffer condition, requeue the same packet, flush, and retry immediately.
6. Drive the kernel into a tight retry loop while holding wl->mutex, resulting in CPU soft lockup and loss of availability.

How to detect it

To assess whether this was already exploited or triggered, review kernel logs, dmesg output, persistent journald records, syslog/kern.log, crash dumps, watchdog resets, and monitoring alerts for CPU soft lockups or hung-task reports involving the wlcore transmit path. Focus on events where call traces include wlcore_tx_work_locked(), wl1271_prepare_tx_frame(), wl1271_tx_allocate(), skb_push(), or pskb_expand_head(), especially if preceded by memory allocation failures, Wi-Fi traffic spikes, repeated interface resets, or unexplained device reboots. Because this vulnerability causes denial of service rather than a persistent compromise, forensic evidence is most likely to appear as kernel warnings, soft-lockup traces, watchdog events, and availability telemetry rather than dropped files or user-space malware artifacts.

• BUG: soft lockup
• watchdog: BUG: soft lockup
• CPU# stuck for
• wlcore_tx_work_locked
• wl1271_prepare_tx_frame
• wl1271_tx_allocate
• pskb_expand_head
• skb_push
• wlcore
• wlcore_sdio
• wl12xx
• wl18xx
• NETDEV WATCHDOG
• kernel: BUG: soft lockup
• kernel: watchdog: BUG: soft lockup

What your security team should do

• Inventory Linux systems and embedded devices that use wlcore, wlcore_sdio, wl12xx, or wl18xx Wi-Fi drivers.
• Prioritize patching systems that rely on Wi-Fi for availability, operate in untrusted wireless environments, or are difficult to physically recover after a lockup.
• Upgrade to a vendor-supported patched kernel and reboot to ensure the fixed kernel is active.
• Where patching is delayed, disable or blacklist affected wlcore modules if Wi-Fi functionality is not required.
• Add monitoring for Linux kernel soft lockup messages and wlcore transmit-path stack traces.
• Review recent dmesg, journald, and kernel logs for signs of prior soft lockups involving wlcore functions.
• Track distribution and device-vendor advisories because exact fixed versions vary by kernel branch and downstream backport policy.