Wind River Support Network

Description

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