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 skbpush"), wl1271txallocate() and with it wl1271preparetxframe() returns -EAGAIN if pskbexpandhead() fails. However, in wlcoretxworklocked(), a return value of -EAGAIN from wl1271preparetxframe() 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 wlcoretxworklocked() holds wl->mutex, and the retry happens immediately with GFPATOMIC, 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel wlcore Wi-Fi driver are affected. The issue occurs in the transmit path when the driver cannot allocate enough packet headroom.
What is the operational impact if the condition is triggered?
The transmit worker can repeatedly retry the same packet while holding a mutex, causing an infinite loop and a CPU soft lockup. The resolved behavior drops the packet when headroom allocation fails, allowing the loop to terminate.
How can I identify the relevant fix in stable kernel sources?
The provided stable references identify fixes at commits 12f9eef39e49716c763714bfda835a733d5f6dea, 46c670ff1ff466e5eccb3940f726586473dc053c, and 980f793645540ca7a6318165cc12f49d5febeb99.