mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] iommufd: Reject opens until module initialization succeeds
@ 2026-10-30  4:23 Kyle Zeng
  2026-10-30 12:08 ` Jason Gunthorpe
  0 siblings, 1 reply; 2+ messages in thread
From: Kyle Zeng @ 2026-10-30  4:23 UTC (permalink / raw)
  To: iommu; +Cc: Jason Gunthorpe, Kevin Tian, linux-kernel, outbounddisclosures

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.

Gate the shared open callback until all fallible initialization has
completed. Publish the ready flag with release semantics and read it
with acquire semantics so successful opens see the initialized state.

An early rejected open also needs to drop its module-backed operations
table. misc_open() holds misc_mtx across the callback, so deregistration
waits for it, but the VFS's fops_put() on the failed open happens later.
Restore the inode's core character-device operations before returning
-ENODEV, avoiding that remaining reference to the failed module.

Fixes: 01f70cbb26ea ("iommufd: Allow iommufd to supply /dev/vfio/vfio")
Fixes: 23a1b46f15d5 ("iommufd/selftest: Make the mock iommu driver into a real driver")
Signed-off-by: Kyle Zeng <kylebot@openai.com>
---
I have a reproducer for this issue and can share via DM

 drivers/iommu/iommufd/main.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c
index 9a921b153162..781a8d63dda9 100644
--- a/drivers/iommu/iommufd/main.c
+++ b/drivers/iommu/iommufd/main.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/mutex.h>
 #include <linux/slab.h>
+#include <linux/smp.h>
 #include <uapi/linux/iommufd.h>
 
 #include "io_pagetable.h"
@@ -30,6 +31,7 @@ struct iommufd_object_ops {
 };
 static const struct iommufd_object_ops iommufd_object_ops[];
 static struct miscdevice vfio_misc_dev;
+static bool iommufd_ready;
 
 struct iommufd_object *_iommufd_object_alloc(struct iommufd_ctx *ictx,
 					     size_t size,
@@ -316,6 +318,17 @@ static int iommufd_fops_open(struct inode *inode, struct file *filp)
 {
 	struct iommufd_ctx *ictx;
 
+	/* Pairs with the ready publication at the end of iommufd_init(). */
+	if (!smp_load_acquire(&iommufd_ready)) {
+		/*
+		 * misc_deregister() waits for this callback, but not the
+		 * VFS's fops_put() after a failed open. Restore the core
+		 * character-device operations before dropping misc_mtx.
+		 */
+		replace_fops(filp, fops_get(inode->i_fop));
+		return -ENODEV;
+	}
+
 	ictx = kzalloc_obj(*ictx, GFP_KERNEL_ACCOUNT);
 	if (!ictx)
 		return -ENOMEM;
@@ -799,6 +812,8 @@ static int __init iommufd_init(void)
 	ret = iommufd_test_init();
 	if (ret)
 		goto err_vfio_misc;
+	/* Pairs with iommufd_fops_open(); no fallible setup may follow. */
+	smp_store_release(&iommufd_ready, true);
 	return 0;
 
 err_vfio_misc:

base-commit: d89e1d186ec9271bf78e62771779e9fc03bf0fc3
-- 
2.56.0

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] iommufd: Reject opens until module initialization succeeds
  2026-10-30  4:23 [PATCH] iommufd: Reject opens until module initialization succeeds Kyle Zeng
@ 2026-10-30 12:08 ` Jason Gunthorpe
  0 siblings, 0 replies; 2+ messages in thread
From: Jason Gunthorpe @ 2026-10-30 12:08 UTC (permalink / raw)
  To: Kyle Zeng; +Cc: iommu, Kevin Tian, linux-kernel, outbounddisclosures

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-10-30 12:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-30  4:23 [PATCH] iommufd: Reject opens until module initialization succeeds Kyle Zeng
2026-10-30 12:08 ` Jason Gunthorpe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®