CVE-2026-46110
published 2026-05-28CVE-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…
high7.5CVSS 3.1
AVNACLPRNUINSUCNINAH
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 `cur_rx` 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 `cur_rx` modulo the
ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
position with `dirty_rx`, 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):
- `empty` (OWN=1, buffer valid)
- `full` (OWN=0, buffer valid and populated)
- `dirty` (OWN=0, buffer NULL)
But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In
the past (see 'Fixes:'), there was a bug where the loop could cycle
`cur_rx` all the way back to the first descriptor it dirtied, resulting
in a NULL dereference when mistaken for `full`. The aforementioned
commit resolved that *specific* failure by capping the loop's iteration
limit at `dma_rx_size - 1`, but this is only a partial fix: if the
previous stmmac_rx_refill() didn't complete, then there are leftover
`dirty`
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 6.1.64 < 6.2 | 6.2 |
| linux | linux | >= 6.5.13 < 6.6 | 6.6 |
| linux | linux | >= 6.6.3 < 6.6.140 | 6.6.140 |
| linux | linux | >= 779334e59850f863bf34665e0ff0b6faf126873b < e1c50b273298c7cd9b08b113e7a7598b531a02f5 | e1c50b273298c7cd9b08b113e7a7598b531a02f5 |
| linux | linux | >= b6cb4541853c7ee512111b0e7ddf3cb66c99c137 < 5c910f7708e3c507b037ca91ca5b09f8cfe71e65 | 5c910f7708e3c507b037ca91ca5b09f8cfe71e65 |
| linux | linux | >= b6cb4541853c7ee512111b0e7ddf3cb66c99c137 < 4af2e62cbcda575a174acd230c3f3a208135e16d | 4af2e62cbcda575a174acd230c3f3a208135e16d |
| linux | linux | >= b6cb4541853c7ee512111b0e7ddf3cb66c99c137 < 950cb436165aad0f8f2cd49da3cd07677465bcde | 950cb436165aad0f8f2cd49da3cd07677465bcde |
| linux | linux | >= b6cb4541853c7ee512111b0e7ddf3cb66c99c137 < 0bb05e6adfa99a2ea1fee1125cc0953409f83ed8 | 0bb05e6adfa99a2ea1fee1125cc0953409f83ed8 |
| linux | linux_kernel | — | — |