Cloudanix VulnDB

CVE-2026-63929

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug leaks small amounts of memory every time certain sensor data buffers are filled, eventually using up all memory and making the computer slow or unusable.

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

What it actually does

Unreleased kref on struct iio_dma_fence after dma_resv_add_fence leaves the initial dma_fence_init allocation permanently live, leaking one kmalloc-128 object per successful iio_buffer_enqueue_dmabuf call.

Why it matters to the business

Sustained high-rate DMA buffer usage on IIO devices causes gradual kernel memory exhaustion, leading to slab growth, performance degradation, and eventual system instability or denial of service on affected Linux kernels.

How an attack unfolds

An attacker repeatedly enqueues DMA buffers through the IIO interface; each enqueue leaks a fence object because the success path omits dma_fence_put, while cleanup only releases the temporary reference taken during signalling.

How to fix it

Apply the upstream fix that inserts dma_fence_put after dma_resv_add_fence in iio_buffer_enqueue_dmabuf so ownership of the fence is transferred to the reservation object; rebuild and deploy the corrected kernel.

How to confirm the fix worked

Confirm the dma_fence_put call exists after dma_resv_add_fence; reproduce buffer enqueues under ftrace and verify dma_fence_destroy events are now emitted; monitor kmalloc-128 slab counters for stability during load.

Typical attack path

  1. Obtain access or privileges sufficient to call iio_buffer_enqueue_dmabuf on an IIO device supporting DMA fencing
  2. Issue repeated buffer enqueue operations at high frequency
  3. Observe progressive growth of kmalloc-128 allocations without corresponding dma_fence_destroy events
  4. Continue until memory pressure triggers instability or OOM

How to detect it

Correlate IIO buffer enqueue activity with continuous growth of kmalloc-128 objects; use ftrace or slabinfo to confirm absence of dma_fence_destroy events for iio_dma_fence objects.

What your security team should do

  • Patch kernels containing the IIO DMA buffer code as soon as fixed packages are available
  • Restrict unprivileged access to IIO character devices and DMA buffer enqueue paths
  • Add monitoring for anomalous kmalloc-128 slab growth correlated with IIO activity

The record

In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf() iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes, kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial kref to 1. It then calls dma_resv_add_fence() which takes a second reference (kref=2), and stores a raw pointer in block->fence. On the success path the function returns without calling dma_fence_put() to release the initial reference, so every buffer enqueue permanently leaks one kmalloc-128 allocation. The iio_buffer_cleanup() work item only releases the temporary reference taken during completion signalling by iio_buffer_signal_dmabuf_done(); the initial reference from dma_fence_init() is never released. With four iio_rwdev instances at 240kHz and 512 samples per buffer, this produces ~1875 kmalloc-128 allocations per second matching the observed slab growth exactly. A test with ftrace confirmed that the dma_fence_destroy event was never triggered. Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring ownership of the fence to the DMA reservation object. The DMA fence then gets properly discarded after being signalled.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities