In the Linux kernel, the following vulnerability has been resolved:
iio: buffer: Make IIO DMA fence release RCU-safe
The dma_fence documentation states that if a custom release
implementation is provided, the dma_fence object must be freed in an
RCU-safe way. The current iio_dma_fence implementation uses kfree(),
which might result in a use-after-free.
Remove the custom release implementation. This makes the DMA fence core
fall back to dma_fence_free(), which calls kfree_rcu() on the fence.
This requires that the fence be the first member of struct iio_dma_fence.
Using the default release method for extended DMA fence structures is a
common pattern.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The use-after-free is reached only through local IIO character-device ioctls (IIO_BUFFER_GET_FD_IOCTL then IIO_BUFFER_DMABUF_ATTACH/ENQUEUE_IOCTL on /dev/iio:deviceN); there is no network, Bluetooth, or USB packet path into the IIO DMA fence release.
AC:L - The attacker controls both sides of the race by enqueueing IIO DMA-BUF transfers that create and later kfree() the fence while concurrently waiting on or exporting the same dma-buf's reservation fences via DMA_BUF_IOCTL_SYNC/EXPORT_SYNC_FILE, so the missing RCU grace period is attacker-driven.
PR:L - The IIO open and ioctl path performs no capability check; only filesystem access to /dev/iio:deviceN is required. On Android, automotive, and industrial/SDR systems that ship DMA-capable IIO converters, that node is commonly group-accessible to unprivileged sensor or application users.
UI:N - The attacker opens the IIO device, attaches their own DMA-BUF, and issues enqueue and dma-buf sync/export ioctls themselves; no separate victim action is required.
S:U - The freed iio_dma_fence lives in the host kernel heap and any resulting corruption stays within the same kernel security authority; this is not a VM escape or IOMMU/DMA boundary bypass.
C:H - Immediate kfree() of the dma_fence lets concurrent dma_resv RCU walkers (dma_fence_get_rcu, dma_fence_driver_name) read the reclaimed slab object; per kernel scoring guidance a use-after-free is High confidentiality impact.
I:H - The freed dma_fence contains ops function pointers, callback lists, and a spinlock used after free; reclaiming the object with attacker-controlled data yields write and control-flow hijack primitives, so integrity impact is High.
A:H - Use-after-free of the fence from dma_fence_release or dma_resv iteration causes a kernel oops or panic even without a full exploit, so availability impact is High.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The use-after-free is reached only through local IIO character-device ioctls (IIO_BUFFER_GET_FD_IOCTL then IIO_BUFFER_DMABUF_ATTACH/ENQUEUE_IOCTL on /dev/iio:deviceN); there is no network, Bluetooth, or USB packet path into the IIO DMA fence release.
AC:L - The attacker controls both sides of the race by enqueueing IIO DMA-BUF transfers that create and later kfree() the fence while concurrently waiting on or exporting the same dma-buf's reservation fences via DMA_BUF_IOCTL_SYNC/EXPORT_SYNC_FILE, so the missing RCU grace period is attacker-driven.
PR:L - The IIO open and ioctl path performs no capability check; only filesystem access to /dev/iio:deviceN is required. On Android, automotive, and industrial/SDR systems that ship DMA-capable IIO converters, that node is commonly group-accessible to unprivileged sensor or application users.
UI:N - The attacker opens the IIO device, attaches their own DMA-BUF, and issues enqueue and dma-buf sync/export ioctls themselves; no separate victim action is required.
S:U - The freed iio_dma_fence lives in the host kernel heap and any resulting corruption stays within the same kernel security authority; this is not a VM escape or IOMMU/DMA boundary bypass.
C:H - Immediate kfree() of the dma_fence lets concurrent dma_resv RCU walkers (dma_fence_get_rcu, dma_fence_driver_name) read the reclaimed slab object; per kernel scoring guidance a use-after-free is High confidentiality impact.
I:H - The freed dma_fence contains ops function pointers, callback lists, and a spinlock used after free; reclaiming the object with attacker-controlled data yields write and control-flow hijack primitives, so integrity impact is High.
A:H - Use-after-free of the fence from dma_fence_release or dma_resv iteration causes a kernel oops or panic even without a full exploit, so availability impact is High.
CVSS 3.1