CVE-2026-74623

net: atlantic: free stranded TX buffers on ring deinit

N/A
Published: August 22, 2026 at 03:32 PM UTC
Updated: October 14, 2026 at 01:10 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free stranded TX buffers on ring deinit aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() 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/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and "page_pool_release_retry() stalled pool shutdown" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.11eb36bedf28be6d986bdbcfa375bab08ffa45efd8
Vendor states this is fixed in 307d80193b4a4a75b8dc4e0d3162be3755abbed7 (fixed)
Vendor states this is fixed in 3447641d361dcc5511841d986ad4d849b2900d9b (fixed)
Vendor states this is fixed in 452636ea5410a96e02ebaaf80b21e3620b98e0dd (fixed)
Vendor states this is fixed in 4f1c20873f70b4b22ef86dc38dad1fda8e169bcd (fixed)
Vendor states this is fixed in 7a3e1481f4ee6c581bccc6bfc6c970aac5be7b0c (fixed)
Vendor states this is fixed in a14ceebd13bf857bfca052bc5a6bd49e737912be (fixed)
Vendor states this is fixed in b13202d401e1a20fec89b0cda733dcbaf279f79d (fixed)
Vendor states this is fixed in dd633280de7fdfd60dc4fcf63d04e2ad95b43269 (fixed)
Vendor states this is fixed in 4.11 (unaffected)
Vendor states this is fixed in 5.10.266 (unaffected)
Vendor states this is fixed in 5.15.217 (unaffected)
Vendor states this is fixed in 6.1.183 (unaffected)
Vendor states this is fixed in 6.12.104 (unaffected)
Vendor states this is fixed in 6.18.45 (unaffected)
Vendor states this is fixed in 6.6.152 (unaffected)
Vendor states this is fixed in 7.1.9 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card