CVE-2026-43371

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: Shuffle the tx ring before enabling tx<br /> <br /> Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board,<br /> the rootfs may take an extended time to recover after a suspend.<br /> Upon investigation, it was determined that the issue originates from a<br /> problem in the macb driver.<br /> <br /> According to the Zynq UltraScale TRM [1], when transmit is disabled,<br /> the transmit buffer queue pointer resets to point to the address<br /> specified by the transmit buffer queue base address register.<br /> <br /> In the current implementation, the code merely resets `queue-&gt;tx_head`<br /> and `queue-&gt;tx_tail` to &amp;#39;0&amp;#39;. This approach presents several issues:<br /> <br /> - Packets already queued in the tx ring are silently lost,<br /> leading to memory leaks since the associated skbs cannot be released.<br /> <br /> - Concurrent write access to `queue-&gt;tx_head` and `queue-&gt;tx_tail` may<br /> occur from `macb_tx_poll()` or `macb_start_xmit()` when these values<br /> are reset to &amp;#39;0&amp;#39;.<br /> <br /> - The transmission may become stuck on a packet that has already been sent<br /> out, with its &amp;#39;TX_USED&amp;#39; bit set, but has not yet been processed. However,<br /> due to the manipulation of &amp;#39;queue-&gt;tx_head&amp;#39; and &amp;#39;queue-&gt;tx_tail&amp;#39;,<br /> `macb_tx_poll()` incorrectly assumes there are no packets to handle<br /> because `queue-&gt;tx_head == queue-&gt;tx_tail`. This issue is only resolved<br /> when a new packet is placed at this position. This is the root cause of<br /> the prolonged recovery time observed for the NFS root filesystem.<br /> <br /> To resolve this issue, shuffle the tx ring and tx skb array so that<br /> the first unsent packet is positioned at the start of the tx ring.<br /> Additionally, ensure that updates to `queue-&gt;tx_head` and<br /> `queue-&gt;tx_tail` are properly protected with the appropriate lock.<br /> <br /> [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm