CVE-2026-46110

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Prevent NULL deref when RX memory exhausted<br /> <br /> The CPU receives frames from the MAC through conventional DMA: the CPU<br /> allocates buffers for the MAC, then the MAC fills them and returns<br /> ownership to the CPU. For each hardware RX queue, the CPU and MAC<br /> coordinate through a shared ring array of DMA descriptors: one<br /> descriptor per DMA buffer. Each descriptor includes the buffer&amp;#39;s<br /> physical address and a status flag ("OWN") indicating which side owns<br /> the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set<br /> the flag and the MAC is only allowed to clear it, and both must move<br /> through the ring in sequence: thus the ring is used for both<br /> "submissions" and "completions."<br /> <br /> In the stmmac driver, stmmac_rx() bookmarks its position in the ring<br /> with the `cur_rx` index. The main receive loop in that function checks<br /> for rx_descs[cur_rx].own=0, gives the corresponding buffer to the<br /> network stack (NULLing the pointer), and increments `cur_rx` modulo the<br /> ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its<br /> position with `dirty_rx`, allocates fresh buffers and rearms the<br /> descriptors (setting OWN=1). If it fails any allocation, it simply stops<br /> early (leaving OWN=0) and will retry where it left off when next called.<br /> <br /> This means descriptors have a three-stage lifecycle (terms my own):<br /> - `empty` (OWN=1, buffer valid)<br /> - `full` (OWN=0, buffer valid and populated)<br /> - `dirty` (OWN=0, buffer NULL)<br /> <br /> But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In<br /> the past (see &amp;#39;Fixes:&amp;#39;), there was a bug where the loop could cycle<br /> `cur_rx` all the way back to the first descriptor it dirtied, resulting<br /> in a NULL dereference when mistaken for `full`. The aforementioned<br /> commit resolved that *specific* failure by capping the loop&amp;#39;s iteration<br /> limit at `dma_rx_size - 1`, but this is only a partial fix: if the<br /> previous stmmac_rx_refill() didn&amp;#39;t complete, then there are leftover<br /> `dirty` descriptors that the loop might encounter without needing to<br /> cycle fully around. The current code therefore panics (see &amp;#39;Closes:&amp;#39;)<br /> when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to<br /> catch up to `dirty_rx`.<br /> <br /> Fix this by explicitly checking, before advancing `cur_rx`, if the next<br /> entry is dirty; exit the loop if so. This prevents processing of the<br /> final, used descriptor until stmmac_rx_refill() succeeds, but<br /> fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix<br /> intended: so remove the clamp as well. Since stmmac_rx_zc() is a<br /> copy-paste-and-tweak of stmmac_rx() and the code structure is identical,<br /> any fix to stmmac_rx() will also need a corresponding fix for<br /> stmmac_rx_zc(). Therefore, apply the same check there.<br /> <br /> In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the<br /> MAC sets OWN=0 on the final descriptor, it will be unable to send any<br /> further DMA-complete IRQs until it&amp;#39;s given more `empty` descriptors.<br /> Currently, the driver simply *hopes* that the next stmmac_rx_refill()<br /> succeeds, risking an indefinite stall of the receive process if not. But<br /> this is not a regression, so it can be addressed in a future change.