CVE-2026-74623: net: atlantic: free stranded TX buffers on ring deinit
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: free stranded TX buffers on ring deinit
aqvecdeinit() drains the TX rings with a single aqringtxclean() call, which frees at most AQCFGTXCLEANBUDGET (256) descriptors and stops at hwhead, which no longer moves once aqvecstop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hwhead, swtail) keep their skb or xdpframe when the interface goes down: aqvecringfree() then frees the buffer ring and the references are lost for good.
Today this is a silent memory leak on every interface down under TX/XDPTX load. With the conversion of the RX path to pagepool posted for net-next it becomes much more visible: XDPTX frames carry fragment references on the RX ring's pagepool, so a single stranded frame keeps the pool's inflight count above zero forever. pagepooldestroy() then never completes, the pool is leaked together with its pages, and "pagepoolreleaseretry() stalled pool shutdown" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDPTX load.
Bring back aqringtxdeinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdpframes nowadays, so release those too. They are returned with xdpreturnframe() since this runs in process context.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel Atlantic network driver are affected when the interface is brought down while TX or XDP_TX traffic is active. XDP_TX use also makes XDP detach and ring-resize operations relevant triggers.
What operational events can trigger the leak?
The leak can occur during interface shutdown after TX/XDP_TX load, because TX descriptors beyond the cleanup budget or still posted to hardware are not released. Under XDP_TX load, it can also occur on XDP detach or ring resize.
How can I identify the more visible XDP-related failure mode?
Affected systems using the page_pool-based RX path with XDP_TX may repeatedly log "page_pool_release_retry() stalled pool shutdown" every 60 seconds. This indicates that stranded XDP_TX frames have kept the page pool's inflight count above zero, preventing pool destruction.