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.

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-63929)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
343049	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500248)	Nessus	Oracle Linux Local Security Checks	Local	high
340681	Ubuntu 24.04 LTS / 26.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-8663-1)	Nessus	Ubuntu Local Security Checks	Local	high
340045	Ubuntu 26.04 LTS : Linux kernel (NVIDIA BaseOS) vulnerabilities (USN-8664-1)	Nessus	Ubuntu Local Security Checks	Local	high
335080	openSUSE 16: cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:21555-1)	Nessus	SuSE Local Security Checks	Local	high
333762	Photon OS 5.0: Linux PHSA-2026-5.0-92-0895	Nessus	PhotonOS Local Security Checks	Local	high
328275	Linux Distros Unpatched Vulnerability : CVE-2026-63929	Nessus	Misc.	Local	high
322944	Photon OS 5.0: Linux PHSA-2026-5.0-0895	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2026-63929

medium

Tenable Plugins

high

high

high

high

high

high

high