GHSA-5HFJ-3VGW-HM4R
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-19 15:33In 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 descriptors that the loop might encounter without needing to
cycle fully around. The current code therefore panics (see 'Closes:')
when stmmac_rx_refill() is memory-starved long enough for cur_rx to
catch up to dirty_rx.
Fix this by explicitly checking, before advancing cur_rx, if the next
entry is dirty; exit the loop if so. This prevents processing of the
final, used descriptor until stmmac_rx_refill() succeeds, but
fully prevents the cur_rx == dirty_rx ambiguity as the previous bugfix
intended: so remove the clamp as well. Since stmmac_rx_zc() is a
copy-paste-and-tweak of stmmac_rx() and the code structure is identical,
any fix to stmmac_rx() will also need a corresponding fix for
stmmac_rx_zc(). Therefore, apply the same check there.
In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the
MAC sets OWN=0 on the final descriptor, it will be unable to send any
further DMA-complete IRQs until it's given more empty descriptors.
Currently, the driver simply hopes that the next stmmac_rx_refill()
succeeds, risking an indefinite stall of the receive process if not. But
this is not a regression, so it can be addressed in a future change.
{
"affected": [],
"aliases": [
"CVE-2026-46110"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:26Z",
"severity": "HIGH"
},
"details": "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\u0027s\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 \u0027Fixes:\u0027), 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\u0027s iteration\nlimit at `dma_rx_size - 1`, but this is only a partial fix: if the\nprevious stmmac_rx_refill() didn\u0027t 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 \u0027Closes:\u0027)\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\u0027s 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.",
"id": "GHSA-5hfj-3vgw-hm4r",
"modified": "2026-06-19T15:33:13Z",
"published": "2026-05-28T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46110"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4af2e62cbcda575a174acd230c3f3a208135e16d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c910f7708e3c507b037ca91ca5b09f8cfe71e65"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/950cb436165aad0f8f2cd49da3cd07677465bcde"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e1c50b273298c7cd9b08b113e7a7598b531a02f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fdeb95b1fc7de25c9362990efb9996a8d761055c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.