Re: [PATCH] misc: phantom: fix open file UAF after device removal

[Greg KH]

On Tue, Sep 01, 2026 at 05:30:08PM +0700, Anh Khoa Vũ Nguyễn wrote:
> Hi Greg,
> 
> Thanks for the review.
> 
> This was found by source audit, not by a runtime crash report.
> 
> I was checking char drivers for the pattern where:
> - ->open() stores a raw device pointer in file->private_data,
> - ->remove() calls cdev_del() and frees the enclosing object, and
> - already-open file descriptors can still reach
> ->ioctl()/->poll()/->release()
>   after cdev_del() returns.
> 
> phantom.c seemed to match that pattern:
> - phantom_open() stores struct phantom_device * in file->private_data
> - phantom_remove() calls cdev_del() and then kfree(pht)
> - phantom_ioctl(), phantom_poll(), and phantom_release() all dereference
>   file->private_data
> - __fput() calls ->release() before cdev_put(), so the enclosing object
>   still needs to remain valid for an already-open file
> 
> The remove path I had in mind was manual driver unbind while the device node
> is still open, e.g.
> 
>   echo -n 0000:BB:DD.F > /sys/bus/pci/drivers/phantom/unbind
> 
> That should call phantom_remove() even if a userspace process still has
> /dev/phantomX open. The open file pins the module via .owner, but it does
> not pin struct phantom_device itself.
> 
> I should have been clearer in the changelog that this was an audit-found
> lifetime issue and that the trigger I had in mind was sysfs unbind.
> 
> As for testing, I only compile-tested the patch and ran checkpatch. I do not
> have Phantom hardware, so I have not reproduced this on a live system.
> 
> Also, yes, I can simplify the locking change and use a guard/scoped_guard
> helper in a v2 if the issue is worth pursuing.
> 
> If this is considered too theoretical without runtime confirmation on actual
> hardware, I understand and can drop the patch.

Please test it properly and send an update if you wish for it to be
accepted.

thanks,

greg k-h