{“lastseen”:””,”description”:”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 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.”,”published”:”2026-05-28T09:35:18.359Z”,”modified”:”2026-05-30T10:47:40.882Z”,”type”:”cve”,”title”:”net: stmmac: Prevent NULL deref when RX memory exhausted”,”source”:”Linux”,”references”:”https:\/\/git.kernel.org\/stable\/c\/e1c50b273298c7cd9b08b113e7a7598b531a02f5\\nhttps:\/\/git.kernel.org\/stable\/c\/5c910f7708e3c507b037ca91ca5b09f8cfe71e65\\nhttps:\/\/git.kernel.org\/stable\/c\/4af2e62cbcda575a174acd230c3f3a208135e16d\\nhttps:\/\/git.kernel.org\/stable\/c\/950cb436165aad0f8f2cd49da3cd07677465bcde\\nhttps:\/\/git.kernel.org\/stable\/c\/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8″,”id”:”CVE-2026-46110″,”bulletinFamily”:””,”cwe”:null,”cvelist”:null,”sourceData”:”Linux Linux 779334e59850f863bf34665e0ff0b6faf126873b\\nLinux Linux b6cb4541853c7ee512111b0e7ddf3cb66c99c137\\nLinux Linux b6cb4541853c7ee512111b0e7ddf3cb66c99c137\\nLinux Linux b6cb4541853c7ee512111b0e7ddf3cb66c99c137\\nLinux Linux b6cb4541853c7ee512111b0e7ddf3cb66c99c137\\nLinux Linux 7414a28de1b3b028714859078c00a874f9feff52\\nLinux Linux b435b4573240b5530830a1a60e005c6fcfd928a0\\nLinux Linux 6.6.3\\nLinux Linux 6.1.64\\nLinux Linux 6.5.13\\nLinux Linux 6.7″,”sourceHref”:””,”cvss”:{“score”:7.5,”severity”:”HIGH”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:N\/UI:N\/S:U\/C:N\/I:N\/A:H”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:””,”category_name”:”CVE”,”post_link”:””,”product”:”Linux”,”version”:”779334e59850f863bf34665e0ff0b6faf126873b”,”vendor”:”Linux”,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:””,”description”:”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…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[6,8,16,12,15,13,7,11,5],"class_list":["post-58480","post","type-post","status-publish","format-standard","hentry","category-category_cve","tag-cve","tag-cvss","tag-cvss-75","tag-exploit","tag-high","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n