CVE-2026-46110 — net: stmmac: Prevent NULL deref when RX memory exhausted
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` 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.
Who exploits it and how urgent it is
A 0–100 score combining confirmed exploitation, ransomware and APT use, public exploits, EPSS and severity.
How the score was calculated
- EPSS 0.7% (30-day exploitation probability)+8
- Technical severity (high)+6
The score orders the patch queue; it does not replace your asset context (internet exposure, criticality, compensating controls).
Triage
Is it exploited, how likely is exploitation, what does it touch, and how severe do the sources call it.
Remediation
Fixes and mitigations documented by the sources — linked to the original advisory.
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
- Documented patch — git.kernel.org (NIST National Vulnerability Database)
First 24 hours
Ordered from the record’s own fields — exposure first, because you cannot patch what you have not found. A rule-generated starting point.
- Identify exposed assets running the affected vendor/product/version combinations (Linux Linux, Linux Linux Kernel).
- The attack is network-based and needs no privileges: restrict exposure (ACLs, VPN, WAF) until patched.
- Apply the fixed version or the patch documented under Remediation.
- Search available logs for exploit probes matching the vulnerability class (memory corruption), errors and authentication anomalies.
Affected scope
Vendor, product and versions as the sources word them.
| Vendor | Product | Versions | Status | Source |
|---|---|---|---|---|
| Linux | Linux |
version 6.7≥ 6.5.13 and < 6.6≥ 6.6.3 and < 6.6.140≥ 6.1.64 and < 6.1.176version b435b4573240b5530830a1a60e005c6fcfd928a0≥ b6cb4541853c7ee512111b0e7ddf3cb66c99c137 and < 0bb05e6adfa99a2ea1fee1125cc0953409f83ed8≥ b6cb4541853c7ee512111b0e7ddf3cb66c99c137 and < 950cb436165aad0f8f2cd49da3cd07677465bcde≥ b6cb4541853c7ee512111b0e7ddf3cb66c99c137 and < 4af2e62cbcda575a174acd230c3f3a208135e16d and 3 more≥ b6cb4541853c7ee512111b0e7ddf3cb66c99c137 and < 5c910f7708e3c507b037ca91ca5b09f8cfe71e65≥ 779334e59850f863bf34665e0ff0b6faf126873b and < e1c50b273298c7cd9b08b113e7a7598b531a02f5≥ 7414a28de1b3b028714859078c00a874f9feff52 and < fdeb95b1fc7de25c9362990efb9996a8d761055c |
Vulnerable | CVE Program (cve.org) e CISA ADP |
| Linux | Linux Kernel |
version 6.7-rc8version 7.1-rc1≥ 6.1.64 and < 6.1.176version 6.7-rc7version 6.7-rc6version 6.7-rc5version 6.7-rc4version 6.7-rc3 and 7 moreversion 6.7-rc2version 6.7≥ 6.19 and < 7.0.7≥ 6.13 and < 6.18.30≥ 6.7.1 and < 6.12.88≥ 6.6.3 and < 6.6.140≥ 6.5.13 and < 6.6 |
Vulnerable | NIST National Vulnerability Database |
Attack characteristics
The CVSS vector, decoded. It describes the attack, not your exposure to it.
Every base score collected
Sources score independently and may disagree; each row says who scored it and under which version.
| Score | Version | Severity | Expl. | Impact | Scored by |
|---|---|---|---|---|---|
| 7.5 | CVSS 3.1 | High | 3.9 | 3.6 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 via NIST National Vulnerability Database |
| 7.5 | CVSS 3.1 | High | — | — | GitHub, Inc. via GitHub Security Advisories |
| 7.5 | CVSS 3.1 | High | — | — | Linux via CVE Program (cve.org) e CISA ADP |
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (score shown at the top: 416baaa9-dc9f-4396-8d5f-8c081fb06d67) Weakness MITRE
Weakness class according to MITRE’s CWE catalog.
EPSS over time FIRST
Oct 13, 2026 → Oct 14, 2026 · 2 reading(s) · max 0.68%
Detection
Read off the CVSS vector and the weakness class. Starting points, not tested rules.
- Prioritize edge telemetry for the network-reachable component (proxy, WAF, IDS/IPS).
- Correlate service crashes/restarts with inbound traffic; repeated crashes may indicate attempts.
Timeline
What happened to this CVE, newest first.
- 2026
- Affected products added · linux/linux
- Record published
- Fix documented
- CVSS changed · 7.5
- Source status changed · → Undergoing Analysis
- Record created in this database
- CVE published
Source activity
Repeated readings are counted rather than listed.
- 2× References added · Oct 14, 2026 – Oct 14, 2026
- 1× Official description updated · Oct 13, 2026 – Oct 13, 2026
References
9 on the record
- git.kernel.org/stable/c/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8
- git.kernel.org/stable/c/4af2e62cbcda575a174acd230c3f3a208135e16d
- git.kernel.org/stable/c/5c910f7708e3c507b037ca91ca5b09f8cfe71e65
- git.kernel.org/stable/c/e1c50b273298c7cd9b08b113e7a7598b531a02f5
- git.kernel.org/stable/c/950cb436165aad0f8f2cd49da3cd07677465bcde
- git.kernel.org/stable/c/fdeb95b1fc7de25c9362990efb9996a8d761055c
- github.com/advisories/GHSA-5hfj-3vgw-hm4r
- nvd.nist.gov/vuln/detail/CVE-2026-46110
- cert-portal.siemens.com/productcert/html/ssa-784472.html
Elsewhere on this site
Related CVEs (same products)
- Critical CVE-2026-99999 ipv4: validate checksum_start before completing checksum 9h
- Unknown CVE-2026-98432 ipv4: free inet_opt and ireq_opt after an RCU grace period 9h
- Unknown CVE-2026-98424 wifi: cfg80211: undo netns switch if renaming the wiphy fails 1d
- Unknown CVE-2026-98425 wifi: mac80211: don't warn when an IBSS has no channel to scan 1d
- Unknown CVE-2026-98426 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path 1d
- Unknown CVE-2026-98427 net/sched: codel: bound the dropping loop per dequeue call 1d
Not in any source we poll
Listed rather than left blank: an empty field and an unmeasured one look identical on screen, and only one is a reason to look elsewhere.
- No CISA SSVC assessment.
- No confirmed IOCs, IP addresses, domains, file hashes, or malware artifacts supplied.
- No organization-specific asset inventory, compensating-control status, or patch deployment evidence supplied.
- No exploit packet captures, log samples, or incident case IDs supplied.
Answered from this record
Text assembled only from the fields above — no additional claims.
What should defenders know first?
CVE-2026-46110 is "net: stmmac: Prevent NULL deref when RX memory exhausted", rated High. It affects Linux (Linux); versions are in the scope table. It is not in CISA KEV, which does not rule out exploitation. CVSS 7.5 describes technical severity. EPSS 0.68% estimates the probability of exploitation in 30 days; neither replaces your asset context. First verify whether exposed or business-critical assets run the affected versions, apply vendor fixes or mitigations, and preserve logs for review.
Comments
Moderated technical discussion. Read the community guidelines.
No comments yet.
Sign in or create an account to comment and suggest corrections.