Re: [PATCH] iommufd: Reject opens until module initialization succeeds

[Kyle Zeng]

On Fri, Oct 30, 2026 at 09:08:45AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 29, 2026 at 09:23:45PM -0700, Kyle Zeng wrote:
> > iommufd_init() publishes /dev/iommu before registering the optional
> > /dev/vfio/vfio compatibility node and running the optional self-test
> > initialization. Either later operation can fail. Since file operations
> > can acquire a reference to a COMING module, an already-open file can
> > survive the failed initialization and refer to freed iommufd module
> > memory.
> 
> What? This seems like a core bug not iommufd.
> 
> files take refcounts on their modules when they open via this:
> 
> static const struct file_operations iommufd_fops = {
> 	.owner = THIS_MODULE,
> 
> If the module hasn't even loaded yet I would rather expect the core
> code to not allow the module refcount to be taken, and if it somehow
> succeeds then it shouldn't allow the module to get yanked out from
> under it.
> 
> It is hard to guess what crashes to be more specific, but
> at least misc_deregister() is safe while files are open.
> 
> Though I wonder how module auto loading works..
> 
> Jason

Hi Jason,

Sorry for the confusion. This is supposed to be a two-patch series and I
accidentally dropped the first patch.
I'll resend the patch series. Also, I have a reproducer for this issue
and can provide through DM.

Best,
Kyle