CVE-2026-63929: Linux Kernel Privilege Escalation Flaw

CVE-2026-63929 Overview

CVE-2026-63929 is a memory leak vulnerability in the Linux kernel's Industrial I/O (IIO) subsystem. The flaw resides in iio_buffer_enqueue_dmabuf(), which allocates a struct iio_dma_fence via kmalloc() and dma_fence_init() but fails to release its initial reference count. Each buffer enqueue operation permanently leaks one kmalloc-128 allocation because the function omits the required dma_fence_put() call after dma_resv_add_fence(). Sustained IIO buffer usage produces continuous slab growth that can exhaust kernel memory over time.

Critical Impact
Every DMA buffer enqueue leaks a 128-byte kernel allocation, causing measurable kmalloc-128 slab growth that can lead to kernel memory exhaustion on systems with high-frequency IIO workloads.

Affected Products

Linux kernel builds with the IIO buffer DMA-BUF interface enabled
Systems using IIO-based data acquisition drivers (for example iio_rwdev)
Stable kernel branches prior to the fixes referenced in the kernel.org commits

Discovery Timeline

2026-07-19 - CVE-2026-63929 published to NVD
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-63929

Vulnerability Analysis

The defect is a reference-counting error in the IIO buffer DMA-BUF enqueue path. iio_buffer_enqueue_dmabuf() allocates a 104-byte struct iio_dma_fence (rounded into the kmalloc-128 slab) and calls dma_fence_init(), which sets the fence kref to 1. The function then calls dma_resv_add_fence(), which takes a second reference, bringing the count to 2. It stores a raw pointer to the fence in block->fence and returns success without dropping the initial reference.

Because ownership of the fence must transfer to the DMA reservation object, the missing dma_fence_put() after dma_resv_add_fence() leaves the fence with one permanent reference. When the fence is later signalled and the temporary reference from iio_buffer_signal_dmabuf_done() is released, the reference count decrements from 2 to 1 instead of reaching 0. The dma_fence_destroy path is therefore never invoked, and the allocation persists for the lifetime of the kernel.

Root Cause

The root cause is an unbalanced reference count. dma_fence_init() establishes an initial kref of 1 that the caller owns. dma_resv_add_fence() acquires its own reference and does not consume the caller's. The IIO enqueue path treated dma_resv_add_fence() as if it transferred ownership, so it never released the initializer reference.

Attack Vector

The issue is a resource-exhaustion condition rather than a directly exploitable memory-safety bug. A local workload that repeatedly enqueues DMA-BUF fences through IIO drivers produces continuous slab growth. In the reproducer described in the advisory, four iio_rwdev instances at 240 kHz with 512 samples per buffer generated approximately 1875 kmalloc-128 allocations per second. On long-running systems or embedded devices with high-throughput sensors, this leak can lead to kernel memory pressure and denial of service.

No verified public exploit code is available. The vulnerability is described in prose because the fix is a single missing dma_fence_put() call, and the referenced kernel.org commits contain the authoritative patch.

Detection Methods for CVE-2026-63929

Indicators of Compromise

Steady, unbounded growth of the kmalloc-128 slab reported by /proc/slabinfo or slabtop on systems using IIO DMA-BUF
Absence of dma_fence_destroy events in ftrace while IIO buffer traffic is active
Gradual reduction in available kernel memory (MemAvailable) that correlates with IIO buffer activity

Detection Strategies

Monitor slab cache growth over time and alert on sustained kmalloc-128 expansion tied to IIO workloads
Trace fence lifecycle with ftrace events dma_fence_init and dma_fence_destroy and compare their counts
Correlate kernel version and configuration inventory against the fixed commits listed in the kernel.org references

Monitoring Recommendations

Baseline slab consumption on systems running iio_rwdev or similar high-rate IIO drivers and alert on deviation
Include MemAvailable and slab counters in host telemetry to detect slow-burn kernel memory exhaustion
Track kernel package versions across the fleet to confirm patched builds are deployed

How to Mitigate CVE-2026-63929

Immediate Actions Required

Update to a Linux kernel release that includes the IIO DMA fence leak fix referenced by the kernel.org commits
Identify hosts running IIO DMA-BUF workloads and prioritize patching where slab growth is observable
Schedule reboots on affected systems, because the leaked allocations only clear on kernel restart

Patch Information

The fix adds the missing dma_fence_put() after dma_resv_add_fence() in iio_buffer_enqueue_dmabuf(), transferring fence ownership to the DMA reservation object so the fence is destroyed once signalled. Vendor patches are available in the stable kernel commits 3412a95afaa5, 9678aeed8b77, 96cdeaba6a00, and a093999355084bdbfe6e97f1dd232e58a1525f0b.

Workarounds

Restrict use of IIO DMA-BUF interfaces to trusted workloads until the kernel is updated
Periodically restart affected systems or reload IIO driver modules to reclaim leaked slab allocations
Reduce IIO sample rates or buffer enqueue frequency on unpatched systems to slow the leak

bash

# Confirm the running kernel and inspect kmalloc-128 slab usage
uname -r
grep -E 'kmalloc-128|Name' /proc/slabinfo

# Trace DMA fence lifecycle to verify balanced init/destroy after patching
echo 1 | sudo tee /sys/kernel/debug/tracing/events/dma_fence/enable
sudo cat /sys/kernel/debug/tracing/trace_pipe | grep dma_fence