Findings

CVE-2026-46110

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC throu…

Published May 28, 2026 · updated Oct 15, 2026 · linux linux kernel

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag ("OWN") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both "submissions" and "completions." In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the index. The main receive loop in that function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with , allocates fresh buffers and rearms the descriptors (setting OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - (OWN=1, buffer valid) - (OWN=0, buffer valid and populated) - (OWN=0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses / . In the past (see 'Fixes:'), there was a bug where the loop could cycle all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for . The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at , but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover descriptors that the loop might encounter without needing to cycle fully around. The current code therefore