---
id: "CVE-2026-98592"
kind: "vulnerability"
aliases: ["CVE-2026-98592"]
title: "Linux kernel: SpacemiT Ethernet driver can DMA from freed buffers"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "other"
products: []
ecosystems: []
tags: ["embedded", "linux-kernel", "other", "spacemit"]
not_affected_if: ["no-spacemit-hardware"]
published_at: "2026-10-18T16:17:11+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:21:41+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98592", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel: SpacemiT Ethernet driver can DMA from freed buffers

In the SpacemiT Ethernet driver, a TX descriptor can stay marked as owned by hardware after a fragment mapping failure, pointing at DMA mappings that were already torn down. The DMA engine may then fetch that stale, unmapped address on a later transmit.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Install a Linux kernel build that includes the upstream commit 'net: spacemit: clear TX descriptor on fragment mapping failure'.
- Check the kernel version with `uname -r` and compare it against the distribution's security advisory for this CVE.

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98592

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

net: spacemit: clear TX descriptor on fragment mapping failure

emac_tx_mem_map() writes TX_DESC_0_OWN into the ring descriptor for
every slot beyond old_head as soon as that slot's memset()'d local
copy is committed with "*tx_desc_addr = tx_desc", i.e. before the
buffers for that slot have necessarily all been mapped successfully.
If emac_tx_map_frag() then fails on a later fragment, the err_free_skb
path calls emac_free_tx_buf() to unmap and drop the skb, but leaves
the already-written descriptor memory untouched, and tx_ring->head is
never advanced past old_head (the "tx_ring->head = head" store is
skipped by the goto).

So a slot between old_head and the rolled-back head can be left with
TX_DESC_0_OWN set and buffer_addr_{1,2} pointing at DMA mappings that
emac_free_tx_buf() just tore down, while software considers that slot
free again. The next successful emac_tx_mem_map() call only rebuilds
old_head itself; if the DMA engine auto-advances into the following
descriptor once it finishes old_head's packet, it will fetch that
stale, already-unmapped address.

emac_tx_clean_desc() already treats emac_free_tx_buf() and clearing
the descriptor as a pair when reclaiming completed descriptors; do
the same in the mapping failure path.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_