On 10/21/26 6:47 AM, [email protected] wrote:
[..] Can concurrent DMA_BUF_IOCTL_SET_RELEASE_EVENTFD calls on the same dma-buf race in dma_buf_set_release_eventfd() in drivers/dma-buf/dma-buf.c and cause a use-after-free or leak of struct eventfd_ctx? [..] What happens if more than one process registers a release eventfd on the same struct dma_buf, or if a recipient of the dma-buf fd calls DMA_BUF_IOCTL_SET_RELEASE_EVENTFD? [..] Could that leave the original waiter blocked indefinitely waiting for buffer release, and would a list of registered eventfd contexts (or rejecting re-registration) avoid allowing one holder to disarm another's notification?
Yeeeeeah I guess a "one use only" policy would be better after all, i.e. not allowing replacement. That should solve both of these. I'll probably change it to that in v2.
/** diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index e827c9d20c5d3..566dea778ad06 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -179,5 +179,6 @@ struct dma_buf_import_sync_file { #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64) #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file) #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file) +#define DMA_BUF_IOCTL_SET_RELEASE_EVENTFD _IOW(DMA_BUF_BASE, 4, __u32)[Severity: Medium] Is DMA_BUF_IOCTL_SET_RELEASE_EVENTFD in include/uapi/linux/dma-buf.h intended to take a user pointer to __u32 or a file descriptor value directly? Here DMA_BUF_IOCTL_SET_RELEASE_EVENTFD is defined with _IOW(DMA_BUF_BASE, 4, __u32), which indicates a user pointer argument [..]
I don't see anything in include/uapi/asm-generic/ioctl.h intended for defining value arguments but it's a common thing across the tree..?? :/
~val
