CVE-2026-99028

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A driver bug can waste memory or crash a machine when its network connection is repeatedly turned on and off.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Moderate
Impact: Denial Of Service
Component: OS kernel
Class: Race Condition
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

On ndo_stop the driver calls dmaengine_terminate_sync without running completion callbacks, leaking pre-posted RX SKBs and DMA-mapped TX SKBs; a race between axienet_dma_rx_cb and axienet_stop can also leave a live buffer that is later freed while the DMA engine still owns it, producing a use-after-free.

Why it matters to the business

Repeated interface flaps on systems using the Xilinx AXI Ethernet driver can exhaust limited IOMMU address space or trigger kernel crashes, causing network outages that require reboots to recover.

How an attack unfolds

An attacker with local privileges repeatedly brings the affected interface down and up; each cycle leaks DMA mappings until IOMMU resources are exhausted or triggers the race condition to dereference a freed SKB, resulting in denial of service.

How to fix it

Upgrade to a kernel that contains the referenced fix: clear skb pointers in TX/RX callbacks, add the stopping flag with proper locking around the resubmit path, and unmap/free every live buffer before dma_release_channel.

How to confirm the fix worked

Review the axienet driver source for the @stopping flag, the lock held across the check-and-resubmit sequence, and the explicit unmap/free loop in axienet_stop; test by exercising ifdown/ifup under memory-pressure and IOMMU-enabled configurations.

Typical attack path

Obtain local unprivileged access on a host using the Xilinx axienet driver
Trigger repeated ifdown/ifup cycles against the affected interface
Observe progressive IOMMU aperture exhaustion or kernel oops in the DMA tasklet

How to detect it

Search kernel logs and dmesg for axienet DMA callback warnings, skb leaks, or use-after-free reports around ndo_stop; correlate with frequent interface state changes in network logs.

What your security team should do

Prioritize kernel updates on all systems exposing the Xilinx AXI Ethernet MAC
Restrict unprivileged users from bringing interfaces up/down via capabilities or SELinux policy
Monitor kernel logs for axienet DMA tasklet faults and IOMMU allocation failures

The record

In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Free outstanding DMA buffers on dmaengine stop In the dmaengine path the driver pre-submits RX buffers and holds in-flight TX buffers whose SKBs are DMA-mapped by the driver and freed only in the completion callbacks. On ndo_stop() dmaengine_terminate_sync() aborts these descriptors without running their callbacks, and the driver then frees only the ring shells, leaking every SKB still owned by the engine and its DMA mapping on each ifdown. With 128 RX buffers pre-posted per channel, the mapping leak can eventually exhaust a limited IOMMU aperture. Clear the slot's skb in the TX and RX callbacks so a non-NULL skb marks a slot that still owns a live, DMA-mapped buffer, and on stop unmap and free every such buffer. axienet_dma_rx_cb() runs from the DMA tasklet and re-arms the RX ring on each completion, so it can race axienet_stop(): a completion may submit a fresh buffer after dmaengine_terminate_sync() has returned, leaving the channel armed with a buffer the teardown then frees while the engine may still write into it (dma_release_channel() does not stop it either). Add a lock that axienet_dma_rx_cb() holds across the @stopping check and the resubmit, and axienet_stop() holds to set @stopping before terminating. Once @stopping is set no callback can arm a new buffer, and any armed just before is aborted by the terminate, so teardown only frees buffers the engine no longer owns.

Affected packages

Ecosystem	Package	Introduced	Fixed