CVE-2026-74623 net: atlantic: free stranded TX buffers on ring deinit
A memory leak in the Atlantic network driver causes resource exhaustion and denial of service when interfaces are brought down under load.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-74623?
CVE-2026-74623 is a memory corruption vulnerability in Linux, published on 22 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official 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.
Which versions are affected by CVE-2026-74623?
How do I fix CVE-2026-74623?
Apply the vendor's patch.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2026-74623 being exploited?
There is no known exploitation of CVE-2026-74623 in the wild and no public exploit code.
Sources
Also known as AZL-97170, BELL-CVE-2026-74623, DEBIAN-CVE-2026-74623, GHSA-98pj-4qrw-8mcj, UBUNTU-CVE-2026-74623.