CVE-2026-31552: wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom
In the Linux kernel, the following vulnerability has been resolved:
wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom
Since upstream commit e75665dd0968 ("wifi: wlcore: ensure skb headroom
before skb_push"), wl1271_tx_allocate() and with it
wl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails.
However, in wlcore_tx_work_locked(), a return value of -EAGAIN from
wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being
full. This causes the code to flush the buffer, put the skb back at the
head of the queue, and immediately retry the same skb in a tight while
loop.
Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens
immediately with GFP_ATOMIC, this will result in an infinite loop and a
CPU soft lockup. Return -ENOMEM instead so the packet is dropped and
the loop terminates.
The problem was found by an experimental code review agent based on
gemini-3.1-pro while reviewing backports into v6.18.y.
Security readout for executives and security teams
Plain-English summary
A Linux wlcore Wi-Fi transmission error can trap the CPU in an endless retry loop when a memory expansion fails. This can cause a CPU soft lockup and disrupt availability. The supplied CVSS score is 7.5 (high), with no indicated confidentiality or integrity impact.
Executive priority
Patch promptly on systems that depend on wlcore Wi-Fi, especially embedded or availability-sensitive devices. For systems without wlcore exposure, document the finding as not applicable. The high score reflects denial-of-service impact, but the supplied evidence does not demonstrate active exploitation or reliable remote triggering.
Technical view
When pskb_expand_head() fails, wl1271_prepare_tx_frame() returns -EAGAIN. wlcore_tx_work_locked() misinterprets that result as a full aggregation buffer, then flushes, requeues, and immediately retries while holding wl->mutex. The fix returns -ENOMEM, causing the packet to be dropped and terminating the loop.
Likely exposure
Exposure is limited to Linux systems executing the vulnerable wlcore Wi-Fi transmit path. Systems not using wlcore are unlikely to reach the flaw. The supplied version data mixes commit hashes and release endpoints, so determine exposure by checking vendor backports or the applicable stable fix commit.
Exploitation context
KEV is false, and the supplied sources do not report active exploitation or a public exploit. Although the CVSS vector indicates network reachability, the technical description does not establish that a remote attacker can reliably force the required allocation failure. Availability exploitation remains plausible but unconfirmed.
Researcher notes
The defect is an error-semantics mismatch rather than memory corruption: -EAGAIN selects an immediate retry path, while -ENOMEM terminates processing by dropping the packet. The mutex and GFP_ATOMIC retry make the failure persistent enough to produce a soft lockup. Reliable attacker influence over the allocation failure is not demonstrated.
Mitigation direction
Install a vendor-supported kernel update containing the applicable referenced wlcore fix.
Prioritize wlcore-dependent systems whose availability is operationally important.
If updates are delayed, consult the Linux distributor for supported mitigations; none are named in the bundle.
Monitor affected systems for CPU soft-lockup warnings and resulting service disruption.
Validation and detection
Inventory running kernels and identify systems where wlcore is enabled, loaded, or actively used.
Check deployed build metadata for the applicable stable fix commit or documented vendor backport.
Review kernel logs and monitoring for soft lockups associated with wlcore transmission activity.
After updating and rebooting, confirm the fixed kernel is running across the targeted fleet.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-31552 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
9Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.