On Mon, Jun 10, 2024 at 02:09:06PM -0600, Alex Williamson wrote:
> >
> > We could move vfs_poll() under vm->irqfds_lock, but that smells
> > like asking for deadlocks ;-/
> >
> > vfio_virqfd_enable() has the same problem, except that there we
> > definitely can't move vfs_poll() under the lock - it's a spinlock.
>
> vfio_virqfd_enable() and vfio_virqfd_disable() are serialized by their
> callers, I don't see that they have a UAF problem. Thanks,
>
> Alex
Umm... I agree that there's no UAF on vfio side; acrn and xen/privcmd
counterparts, OTOH, look like they do have that...
OK, so the memory safety in there depends upon
* external exclusion wrt vfio_virqfd_disable() on caller-specific
locks (vfio_pci_core_device::ioeventfds_lock for vfio_pci_rdwr.c,
vfio_pci_core_device::igate for the rest? What about the path via
vfio_pci_core_disable()?)
* no EPOLLHUP on eventfd while the file is pinned. That's what
/*
* Do not drop the file until the irqfd is fully initialized,
* otherwise we might race against the EPOLLHUP.
*/
in there (that "irqfd" is a typo for "kirqfd", right?) refers to.
