Description

In the Linux kernel, the following vulnerability has been resolved: iommufd: Take dma_resv lock before dma_buf_unpin() in release path dma_buf_unpin() requires the caller to hold the exporter's dma_resv lock: void dma_buf_unpin(struct dma_buf_attachment *attach) { ... dma_resv_assert_held(dmabuf->resv); ... } iopt_release_pages() calls dma_buf_unpin() without taking that lock, so every iommufd_ioas_destroy()/iommufd_ioas_unmap() that releases the last reference on a DMABUF-backed iopt_pages triggers a WARN. This was hit while running tools/testing/selftests/iommu/iommufd: WARNING: drivers/dma-buf/dma-buf.c:1137 at dma_buf_unpin+0x62/0x70 RIP: 0010:dma_buf_unpin+0x62/0x70 Call Trace: <TASK> dma_buf_unpin+0x62/0x70 iopt_release_pages+0xe4/0x190 iopt_unmap_iova_range+0x1c7/0x290 iopt_unmap_all+0x1a/0x30 iommufd_ioas_destroy+0x1d/0x50 iommufd_fops_release+0x93/0x150 __fput+0xfc/0x2c0 __x64_sys_close+0x3d/0x80 do_syscall_64+0x65/0x180 </TASK> Take the dma_resv lock around dma_buf_unpin() in iopt_release_pages(), matching the iopt_map_dmabuf() convention. dma_buf_detach() acquires the reservation lock internally, so it must remain outside the locked region.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-28T08:16:48.200Z",
  "pubdate": "2026-08-28T08:16:48.200Z",
  "executiveSummary": "A locking violation vulnerability exists in the Linux kernel's iommufd subsystem, specifically within the iopt_release_pages function. The vulnerability is classified as an improper synchronization issue where the required dma_resv lock is not acquired before invoking dma_buf_unpin.\nThis missing lock enforcement triggers a kernel warning (WARN_ON) whenever an IOAS is destroyed or unmapped while backed by a DMABUF. The vulnerability affects the integrity of the DMA-BUF reservation object management.\nWhile primarily a stability and assertion violation, improper locking in kernel-space resource management can lead to race conditions, potential kernel panics, or memory corruption scenarios if concurrent operations attempt to access the reservation object without proper exclusion.\nThe vulnerability is localized to the iommufd component and requires local access to trigger through the iommufd ioctl interface. There are no authentication requirements beyond having the necessary privileges to interact with the iommufd character device.",
  "technicalDetails": "The root cause of this vulnerability is a violation of the dma_buf_unpin API contract. According to the kernel's internal DMA-BUF specification, the caller must hold the exporter's dma_resv lock when calling dma_buf_unpin to ensure thread-safe synchronization of the underlying reservation object.\nIn the affected kernel implementation, the function iopt_release_pages attempts to perform the unpinning operation during the release path of an IOAS (I/O Address Space). The function fails to implement the mandatory locking sequence prior to the call. Specifically, the execution trace shows that iommufd_ioas_destroy calls iopt_unmap_all, which triggers iopt_unmap_iova_range, eventually reaching the vulnerable iopt_release_pages function.\nThe exploitation flow involves an attacker leveraging the iommufd interface to create an IOAS and map a DMABUF-backed memory region. By subsequently closing the file descriptor or issuing an unmap command, the kernel executes the cleanup path. Because the dma_resv_assert_held(dmabuf->resv) check inside dma_buf_unpin fails, the kernel triggers a stack trace and a warning. In a multi-threaded environment, the lack of locking creates a race condition where the DMA-BUF reservation state could be modified by another kernel component simultaneously, potentially leading to inconsistent memory states or double-free scenarios within the DMA-BUF metadata.\nThe vulnerable code path is identified within the iopt_release_pages function in the iommufd subsystem. Because the DMA-BUF detach operation internally attempts to acquire the reservation lock, it must strictly remain outside the caller-defined locked region established for the unpinning process. Failure to correctly order these operations leads to either deadlocks or, as observed, assertion failures.\nThis issue affects userspace applications utilizing the iommufd framework for DMA-BUF mapping. Privilege escalation is not directly facilitated, but kernel instability resulting from the assertion failure may lead to a denial-of-service condition if the kernel is configured to panic on warnings or if the resulting race condition induces a system crash."
}