Cloudanix VulnDB

CVE-2026-98344

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A counting error in Linux kernel code that manages data transfer hardware can cause unexpected crashes or failures when multiple programs use the same hardware channels.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability causes an underflow of the device reference count (kref) in dma_chan_put() due to unconditional decrements on fast-path get/put pairs, leading to premature device release and subsequent dma_find_channel() returning NULL despite the module being loaded.

Why it matters to the business

System instability or crashes during DMA channel operations, potentially disrupting hardware acceleration and data transfer functions in kernel drivers on affected Linux systems.

How an attack unfolds

An attacker with the ability to interact with DMA engine clients can cycle dmaengine_get()/dmaengine_put() calls while a persistent client maintains client_count > 0, causing the kref to underflow and enabling denial-of-service conditions when the device reference is lost.

How to fix it

Apply the upstream fix ensuring device reference is dropped only on the last put to match slow-path get behavior; rebuild and deploy updated Linux kernels containing the corrected dma_chan_put logic.

How to confirm the fix worked

Inspect kernel source for conditional client_count checks before device ref drop in dma_chan_put, then exercise multi-client DMA get/put workloads to confirm no underflow occurs and dma_find_channel succeeds as expected.

Typical attack path

  1. Identify a non-private DMA provider with persistent client holding client_count > 0
  2. Trigger repeated fast-path dmaengine_get/put cycles from another client
  3. Force kref underflow through mismatched get/put operations
  4. Trigger NULL return from dma_find_channel or subsequent memory corruption

How to detect it

Monitor kernel logs and dmesg for messages about unexpected NULL channel returns, dma_device reference errors, or crashes in dmaengine paths; correlate with processes performing repeated DMA channel acquisition.

What your security team should do

  • Apply kernel updates addressing the DMA reference counting fix at the earliest maintenance window
  • Review custom or third-party DMA client drivers for persistent client_count usage patterns
  • Enable kernel crash and oops logging to capture DMA-related reference errors

The record

In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix device kref underflow in dma_chan_put() dma_chan_get() takes chan->device->ref only on the slow path: /* no kref on fast path */ if (chan->client_count) { __module_get(owner); chan->client_count++; return 0; } if (!try_module_get(owner)) return -ENODEV; if (!dma_device_get(chan->device)) { // calls kref_get_unless_zero() dma_chan_put() drops the ref unconditionally, so every fast-path get/put pair drops one extra device reference. The bug fires when two conditions hold together: a non-private provider has a persistent client holding chan->client_count > 0 and another client cycles dmaengine_get()/dmaengine_put(). When the kref hits zero, the subsequent dma_find_channel() returns NULL even though the provider module is still loaded. Fix this by dropping device->ref only on the last put, matching the single slow-path get.

Affected packages

Ecosystem Package Introduced Fixed