---
id: CVE-2026-46110
title: |-
  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…
summary: |-
  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…
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'
---

## Overview

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.

## 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`

## Remediation

Upgrade past the affected range:

- `linux_kernel 7.0.7`