CVE-2026-89940: iio: buffer: Tie IIO dma fence lock lifetime to the fence
In the Linux kernel, the following vulnerability has been resolved:
iio: buffer: Tie IIO dma fence lock lifetime to the fence
The iiodmafence implementation currently uses a lock embedded in the iiodmabufpriv. But the iiodmafence can outlive the iiodmabufpriv, which can cause a use-after-free.
Tie the lifetime of the lock to the lifetime of the fence by embedding them in the same struct.
We can't just hold a reference to the iiodmabufpriv from the iiodmafence since iiobufferdmabufrelease() might sleep and the fence release callback is not allowed to sleep.
Note that the dmafence framework now has an internal lock that gets used when the passing NULL for lock in dmafenceinit(), but in order to allow this patch to be backportable use an external lock.
Event History
Frequently Asked Questions
What condition is required for this use-after-free to occur?
An IIO DMA fence must outlive the associated iio_dmabuf_priv object. In the affected implementation, the fence then retains use of a lock embedded in memory that may already have been freed.
Why is retaining the iio_dmabuf_priv object until fence destruction not used as the fix?
The iio_buffer_dmabuf_release() path may sleep, while a fence release callback is not allowed to sleep. The fix instead places the lock and fence in the same structure so their lifetimes are tied together.
What change addresses the issue?
The resolved implementation embeds the lock with the iio_dma_fence rather than using a lock embedded in iio_dmabuf_priv. It deliberately uses an external lock to support backporting, despite the dma_fence framework supporting an internal lock when initialized with a NULL lock.