CVE-2025-68232

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: more robust handing of race to avoid txq getting stuck<br /> <br /> Commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to<br /> reduce TX drops") introduced a race condition that can lead to a permanently<br /> stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra<br /> Max).<br /> <br /> The race occurs in veth_xmit(). The producer observes a full ptr_ring and<br /> stops the queue (netif_tx_stop_queue()). The subsequent conditional logic,<br /> intended to re-wake the queue if the consumer had just emptied it (if<br /> (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a<br /> "lost wakeup" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and<br /> traffic halts.<br /> <br /> This failure is caused by an incorrect use of the __ptr_ring_empty() API<br /> from the producer side. As noted in kernel comments, this check is not<br /> guaranteed to be correct if a consumer is operating on another CPU. The<br /> empty test is based on ptr_ring-&gt;consumer_head, making it reliable only for<br /> the consumer. Using this check from the producer side is fundamentally racy.<br /> <br /> This patch fixes the race by adopting the more robust logic from an earlier<br /> version V4 of the patchset, which always flushed the peer:<br /> <br /> (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier<br /> are removed. Instead, after stopping the queue, we unconditionally call<br /> __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled,<br /> making it solely responsible for re-waking the TXQ.<br /> This handles the race where veth_poll() consumes all packets and completes<br /> NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue.<br /> The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule<br /> NAPI.<br /> <br /> (2) On the consumer side, the logic for waking the peer TXQ is moved out of<br /> veth_xdp_rcv() and placed at the end of the veth_poll() function. This<br /> placement is part of fixing the race, as the netif_tx_queue_stopped() check<br /> must occur after rx_notify_masked is potentially set to false during NAPI<br /> completion.<br /> This handles the race where veth_poll() consumes all packets, but haven&amp;#39;t<br /> finished (rx_notify_masked is still true). The producer veth_xmit() stops the<br /> TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning<br /> not starting NAPI. Then veth_poll() change rx_notify_masked to false and<br /> stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake<br /> it up.