CVE-2026-46110 - Vulnerability Details

- net: stmmac: Prevent NULL deref when RX memory exhausted

Description

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.

Published: 2026-05-28

Score: 7.5 High

EPSS: < 1% Very Low

KEV: No

Impact:

Action:

Analysis

Impact

The stmmac driver contains a flaw where the receive loop can treat a descriptor with a NULL buffer as valid, leading to a kernel panic. This results in a denial‑of‑service condition by crashing the operating system rather than enabling code execution. The weakness is a NULL pointer dereference triggered by a missing dirty‑descriptor check during RX ring processing.

Affected Systems

All Linux kernel releases that include the stmmac network driver and have not incorporated the recent patch are affected. The vulnerability is vendor‑agnostic, impacting any system that uses the stmmac driver for Ethernet controller handling.

Risk and Exploitability

With a CVSS score of 7.5 and an EPSS score of < 1%, the vulnerability poses a high severity risk but low likelihood of exploitation. The issue is not listed in the CISA KEV catalog. Attackers would need to generate network traffic that exhausts the RX ring or otherwise triggers the bug, which may require elevated privilege or the ability to send crafted packets to the interface. The likely attack vector is from network packets that fill the receive queue, an inference based on the description of the RAM exhaustion scenario. While the outcome is a service disruption rather than direct code execution, the low EPSS score limits precise risk quantification.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`7414a28de1b3b028714859078c00a874f9feff52`	affected	< fdeb95b1fc7de25c9362990efb9996a8d761055c
`779334e59850f863bf34665e0ff0b6faf126873b`	affected	< e1c50b273298c7cd9b08b113e7a7598b531a02f5
`b6cb4541853c7ee512111b0e7ddf3cb66c99c137`	affected	< 5c910f7708e3c507b037ca91ca5b09f8cfe71e65
`b6cb4541853c7ee512111b0e7ddf3cb66c99c137`	affected	< 4af2e62cbcda575a174acd230c3f3a208135e16d
`b6cb4541853c7ee512111b0e7ddf3cb66c99c137`	affected	< 950cb436165aad0f8f2cd49da3cd07677465bcde
`b6cb4541853c7ee512111b0e7ddf3cb66c99c137`	affected	< 0bb05e6adfa99a2ea1fee1125cc0953409f83ed8
`b435b4573240b5530830a1a60e005c6fcfd928a0`	affected	—
`6.1.64`	affected	< 6.1.176
`6.6.3`	affected	< 6.6.140
`6.5.13`	affected	< 6.6

Linux

affected

Version	Status	Constraints
`6.7`	affected	—
`0`	unaffected	< 6.7
`6.1.176`	unaffected	≤ 6.1.*
`6.6.140`	unaffected	≤ 6.6.*
`6.12.88`	unaffected	≤ 6.12.*
`6.18.30`	unaffected	≤ 6.18.*
`7.0.7`	unaffected	≤ 7.0.*
`7.1`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[779334e59850f863bf34665e0ff0b6faf126873b,e1c50b273298c7cd9b08b113e7a7598b531a02f5)`	affected	code_commit	—
`[b6cb4541853c7ee512111b0e7ddf3cb66c99c137,5c910f7708e3c507b037ca91ca5b09f8cfe71e65)`	affected	code_commit	—
`[b6cb4541853c7ee512111b0e7ddf3cb66c99c137,4af2e62cbcda575a174acd230c3f3a208135e16d)`	affected	code_commit	—
`[b6cb4541853c7ee512111b0e7ddf3cb66c99c137,950cb436165aad0f8f2cd49da3cd07677465bcde)`	affected	code_commit	—
`[b6cb4541853c7ee512111b0e7ddf3cb66c99c137,0bb05e6adfa99a2ea1fee1125cc0953409f83ed8)`	affected	code_commit	—
`7414a28de1b3b028714859078c00a874f9feff52`	affected	code_commit	—
`b435b4573240b5530830a1a60e005c6fcfd928a0`	affected	code_commit	—
`[6.6.3,6.6.140)`	affected	semver	—
`[6.1.64,6.2)`	affected	semver	—
`[6.5.13,6.6)`	affected	semver	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`6.7`	affected	semver	—
`[0,6.7)`	unaffected	semver	—
`[6.6.140,7.0.0)`	unaffected	semver	—
`[6.12.88,6.13.0)`	unaffected	semver	—
`[6.18.30,6.19.0)`	unaffected	semver	—
`[7.0.7,7.1.0)`	unaffected	semver	—
`[7.1-rc2,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

Upgrade the Linux kernel to a version that includes the stmmac driver patch resolving the null dereference bug.
If an immediate kernel upgrade is not feasible, temporarily bring down the affected network interfaces or disable the stmmac driver until a patched kernel is available to avoid triggering the flaw.
Review kernel logs for stmmac‑related panic entries and consider implementing a watchdog or monitoring script that flags RX ring exhaustion, thereby allowing proactive containment until the patch can be applied.

Generated by OpenCVE AI on May 30, 2026 at 13:32 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

Attack Vector Network

Attack Complexity Low

Privileges Required None

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

The EPSS score is 0.00466.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8
https://git.kernel.org/stable/c/4af2e62cbcda575a174acd230c3f3a208135e16d
https://git.kernel.org/stable/c/5c910f7708e3c507b037ca91ca5b09f8cfe71e65
https://git.kernel.org/stable/c/950cb436165aad0f8f2cd49da3cd07677465bcde
https://git.kernel.org/stable/c/e1c50b273298c7cd9b08b113e7a7598b531a02f5
https://git.kernel.org/stable/c/fdeb95b1fc7de25c9362990efb9996a8d761055c
https://lore.kernel.org/linux-cve-announce/2026052812-CVE-2026-46110-9346@gregkh/T
https://nvd.nist.gov/vuln/detail/CVE-2026-46110
https://www.cve.org/CVERecord?id=CVE-2026-46110

History

Fri, 19 Jun 2026 12:45:00 +0000

Type	Values Removed	Values Added
References		https://git.kernel.org/stable/c/fdeb95b1fc7de25c9362990efb9996a8d761055c

Sat, 30 May 2026 11:00:00 +0000

Type	Values Removed	Values Added
Metrics		cvssV3_1 `{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}`

Fri, 29 May 2026 00:15:00 +0000

Type	Values Removed	Values Added
References		https://lore.kernel.org/linux-cve-announce/2026052812-CVE-2026-46110-9346@gregkh/T https://nvd.nist.gov/vuln/detail/CVE-2026-46110 https://www.cve.org/CVERecord?id=CVE-2026-46110

Thu, 28 May 2026 11:45:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-476

Thu, 28 May 2026 10:15:00 +0000

Type	Values Removed	Values Added
Description		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.
Title		net: stmmac: Prevent NULL deref when RX memory exhausted
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8 https://git.kernel.org/stable/c/4af2e62cbcda575a174acd230c3f3a208135e16d https://git.kernel.org/stable/c/5c910f7708e3c507b037ca91ca5b09f8cfe71e65 https://git.kernel.org/stable/c/950cb436165aad0f8f2cd49da3cd07677465bcde https://git.kernel.org/stable/c/e1c50b273298c7cd9b08b113e7a7598b531a02f5

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-05-28T09:35:18.359Z

Updated: 2026-06-19T11:59:33.692Z

Reserved: 2026-05-13T15:03:33.098Z

Link: CVE-2026-46110

Vulnrichment

No data.

NVD

Status : Awaiting Analysis

Published: 2026-05-28T10:16:26.420

Modified: 2026-06-17T10:53:04.993

Link: CVE-2026-46110

Redhat

Severity :

Publid Date: 2026-05-28T00:00:00Z

Links: CVE-2026-46110 - Bugzilla

OpenCVE Enrichment

Updated: 2026-05-30T13:45:24Z

Weaknesses

CWE-476
NULL Pointer Dereference

Impact

Affected Systems

Risk and Exploitability

Tracking

Attack Vector Network

Attack Complexity Low

Privileges Required None

Scope Unchanged

Confidentiality Impact None

Integrity Impact None

Availability Impact High

User Interaction None

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object