Linux kernel SpacemiT emac driver leaves stale TX descriptor
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- —
- Confidentiality · integrity · availability
- —
- Fix status
- Partial Red Hat: 1 without a fix
No CVSS vector from any source. Fix status from CNA and Red Hat.
Summary
The Linux kernel from 6.18 has a flaw in the SpacemiT emac network driver's transmit path. When mapping a later fragment fails, the driver leaves a TX descriptor marked as owned by the DMA engine, while its buffer addresses point at mappings that were already torn down. The DMA engine can then fetch that stale, unmapped address once it finishes the preceding packet.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
Description from the CNA
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.
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
Remediation
Upgrade the Linux kernel to 6.18.55, 7.2.9 or 7.3. Red Hat Enterprise Linux 10 is affected, and Red Hat lists no fix plan for it.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
- Fix · CNA Linux (Linux) Fixed in 6.18.55, 7.2.9, 7.3
Vendor assessments
Red Hat
Red Hat rating: Moderate. Red Hat's page for this CVE →
| Product | Status | Plan or fix |
|---|---|---|
| Red Hat Enterprise Linux 10 | Affected | No fix yet: Fix deferred |
Not affected: 6 products
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 9
- Red Hat OpenShift Container Platform 4
- Red Hat OpenShift Container Platform 5
Timeline
- 2026-10-18 Threatist record created from CVE-2026-98592
- 2026-10-18 Alias added: GHSA-f5v2-jrgp-7g6f
- 2026-10-19 Fix available: Linux/[email protected] · CNA
- 2026-10-20 Affected versions changed · Red Hat
- 2026-10-20 CVSS score added · Red Hat
- 2026-10-30 Affected versions changed · Red Hat
References
More Linux vulnerabilities
- TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
- TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
- TI-2021-02452 Incorrect authorization in Ubuntu linux kernel KEVCVSS 3.1HIGH 8.8
- TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
- TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
- TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
Sources
- CVE-2026-98592 · CVE Program
- CVE-2026-98592 · NVD
- FIRST EPSS
- GHSA-f5v2-jrgp-7g6f · GitHub Advisory Database · CC BY 4.0
- CVE-2026-98592 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences