{"id":"CVE-2026-46110","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Prevent NULL deref when RX memory exhausted\n\nThe CPU receives frames from the MAC through conventional DMA: the CPU\nallocates buffers for the MAC, then the…","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Prevent NULL deref when RX memory exhausted\n\nThe CPU receives frames from the MAC through conventional DMA: the CPU\nallocates buffers for the MAC, then the…","severity":"high","cvss":7.5,"cvssVector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","cwe":["CWE-476"],"vendor":"linux","product":"linux_kernel","affected":["linux_kernel >= 6.1.64, < 6.1.176","linux_kernel >= 6.5.13, < 6.6","linux_kernel >= 6.6.3, < 6.6.140","linux_kernel >= 6.7.1, < 6.12.88","linux_kernel >= 6.13, < 6.18.30","linux_kernel >= 6.19, < 7.0.7","linux_kernel = 6.7","linux_kernel = 7.1"],"patched":["linux_kernel 7.0.7"],"published":"2026-05-28","updated":"2026-10-15","sourceUpdated":"2026-10-15T02:19:43.550","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-46110","references":[{"url":"https://git.kernel.org/stable/c/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/4af2e62cbcda575a174acd230c3f3a208135e16d","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/5c910f7708e3c507b037ca91ca5b09f8cfe71e65","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/950cb436165aad0f8f2cd49da3cd07677465bcde","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/e1c50b273298c7cd9b08b113e7a7598b531a02f5","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/fdeb95b1fc7de25c9362990efb9996a8d761055c","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://cert-portal.siemens.com/productcert/html/ssa-784472.html","label":"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"}],"tags":["nvd","cve.org"],"epss":0.00684,"epssPercentile":0.51473,"ingestedAt":"2026-10-15T03:30:12.887Z","slug":"CVE-2026-46110","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Prevent NULL deref when RX memory exhausted\n\nThe CPU receives frames from the MAC through conventional DMA: the CPU\nallocates buffers for the MAC, then the MAC fills them and returns\nownership to the CPU. For each hardware RX queue, the CPU and MAC\ncoordinate through a shared ring array of DMA descriptors: one\ndescriptor per DMA buffer. Each descriptor includes the buffer's\nphysical address and a status flag (\"OWN\") indicating which side owns\nthe buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set\nthe flag and the MAC is only allowed to clear it, and both must move\nthrough the ring in sequence: thus the ring is used for both\n\"submissions\" and \"completions.\"\n\nIn the stmmac driver, stmmac_rx() bookmarks its position in the ring\nwith the `cur_rx` index. The main receive loop in that function checks\nfor rx_descs[cur_rx].own=0, gives the corresponding buffer to the\nnetwork stack (NULLing the pointer), and increments `cur_rx` modulo the\nring size. After the loop exits, stmmac_rx_refill(), which bookmarks its\nposition with `dirty_rx`, allocates fresh buffers and rearms the\ndescriptors (setting OWN=1). If it fails any allocation, it simply stops\nearly (leaving OWN=0) and will retry where it left off when next called.\n\nThis means descriptors have a three-stage lifecycle (terms my own):\n- `empty` (OWN=1, buffer valid)\n- `full` (OWN=0, buffer valid and populated)\n- `dirty` (OWN=0, buffer NULL)\n\nBut because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In\nthe past (see 'Fixes:'), there was a bug where the loop could cycle\n`cur_rx` all the way back to the first descriptor it dirtied, resulting\nin a NULL dereference when mistaken for `full`. The aforementioned\ncommit resolved that *specific* failure by capping the loop's iteration\nlimit at `dma_rx_size - 1`, but this is only a partial fix: if the\nprevious stmmac_rx_refill() didn't complete, then there are leftover\n`dirty` descriptors that the loop might encounter without needing to\ncycle fully around. The current code therefore panics (see 'Closes:')\nwhen stmmac_rx_refill() is memory-starved long enough for `cur_rx` to\ncatch up to `dirty_rx`.\n\nFix this by explicitly checking, before advancing `cur_rx`, if the next\nentry is dirty; exit the loop if so. This prevents processing of the\nfinal, used descriptor until stmmac_rx_refill() succeeds, but\nfully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix\nintended: so remove the clamp as well. Since stmmac_rx_zc() is a\ncopy-paste-and-tweak of stmmac_rx() and the code structure is identical,\nany fix to stmmac_rx() will also need a corresponding fix for\nstmmac_rx_zc(). Therefore, apply the same check there.\n\nIn stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the\nMAC sets OWN=0 on the final descriptor, it will be unable to send any\nfurther DMA-complete IRQs until it's given more `empty` descriptors.\nCurrently, the driver simply *hopes* that the next stmmac_rx_refill()\nsucceeds, risking an indefinite stall of the receive process if not. But\nthis is not a regression, so it can be addressed in a future change.\n\n## Affected\n\n- `linux_kernel >= 6.1.64, < 6.1.176`\n- `linux_kernel >= 6.5.13, < 6.6`\n- `linux_kernel >= 6.6.3, < 6.6.140`\n- `linux_kernel >= 6.7.1, < 6.12.88`\n- `linux_kernel >= 6.13, < 6.18.30`\n- `linux_kernel >= 6.19, < 7.0.7`\n- `linux_kernel = 6.7`\n- `linux_kernel = 7.1`\n\n## Remediation\n\nUpgrade past the affected range:\n\n- `linux_kernel 7.0.7`","depth":"twilight","depthScore":41,"depthScoreParts":{"impact":41.3,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}