[PATCH v2] params: serialize lookup_or_create_module_kobject()

[PATCH v2] params: serialize lookup_or_create_module_kobject()

[Jiakai Xu]

lookup_or_create_module_kobject() first looks up the module kobject with
kset_find_obj() and, if not found, creates a new one with
kobject_init_and_add().  The function is called at runtime from
module_add_driver() since commit f95bbfe18512 ("drivers: base: handle
module_kobject creation"), which means two concurrent driver
registrations for the same built-in module name can both miss the
lookup and race to create the same kobject.

The loser of the race gets -EEXIST from kobject_init_and_add() and its
kobject is removed from module_kset by kobject_add_internal() before
the failure is reported.  The error path then calls kobject_put(),
which invokes module_kobj_release(), but that only completes
->kobj_completion and never frees the dynamically allocated
module_kobject, leaking it (96 bytes) along with the object having been
detached from the kset.

This is triggerable by unprivileged users, e.g. by concurrently issuing
the RAW_IOCTL_INIT ioctl of the raw-gadget driver, which registers the
"raw_gadget" driver on the gadget bus:

  sysfs: cannot create duplicate filename '/module/raw_gadget'
  ...
  Adding module 'raw_gadget' to sysfs failed (-17), the system may be
  unstable.
  ...
  unreferenced object 0xffff8880188dacc0 (size 96):
    backtrace:
      lookup_or_create_module_kobject+0x47/0x100
      module_add_driver+0x73/0x1b0
      bus_add_driver+0x1d9/0x340
      driver_register+0xde/0x170

Fix it by serializing the lookup and the creation with a mutex, so that
the second caller finds the kobject created by the first one instead of
racing with it.

Fixes: f95bbfe18512 ("drivers: base: handle module_kobject creation")
Fixes: 7c76c813cfc4 ("kernel: globalize lookup_or_create_module_kobject()")
Cc: stable@vger.kernel.org   # v6.15+
Assisted-by: OpenCode:DeepSeek-V4-Flash
Signed-off-by: Jiakai Xu <xujiakai24@mails.ucas.ac.cn>
---
V1 -> V2:
- Use guard(mutex) to hold mod_kobject_mutex instead of the explicit
  mutex_lock()/mutex_unlock() pair with the goto out unwinding, as
  suggested by Greg Kroah-Hartman.
- Fix the multi-line comment style at the mod_kobject_mutex
  declaration ("/*" on its own line).
- Add the missing "Cc: stable@vger.kernel.org" tag, as both Fixes
  commits are in v6.15.
- Add the "Assisted-by: OpenCode:DeepSeek-V4-Flash" tag per
  Documentation/process/coding-assistants.rst.

V1: https://lore.kernel.org/all/20260918013445.1849655-1-xujiakai24@mails.ucas.ac.cn/
---

 kernel/params.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/kernel/params.c b/kernel/params.c
index 8b25133fed242..a45a0201cb4fb 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -3,6 +3,7 @@
  * Helpers for initial module or kernel cmdline parsing
  * Copyright (C) 2001 Rusty Russell.
  */
+#include <linux/cleanup.h>
 #include <linux/ctype.h>
 #include <linux/device.h>
 #include <linux/err.h>
@@ -20,6 +21,12 @@
 /* Protects all built-in parameters, modules use their own param_lock */
 static DEFINE_MUTEX(param_lock);
 
+/*
+ * Serializes module kobject lookup and creation in
+ * lookup_or_create_module_kobject()
+ */
+static DEFINE_MUTEX(mod_kobject_mutex);
+
 /* Use the module's mutex, or if built-in use the built-in mutex */
 #ifdef CONFIG_MODULES
 #define KPARAM_MUTEX(mod)	((mod) ? &(mod)->param_lock : &param_lock)
@@ -754,6 +761,13 @@ lookup_or_create_module_kobject(const char *name)
 	struct kobject *kobj;
 	int err;
 
+	/*
+	 * The lookup and the creation must be done atomically, otherwise
+	 * concurrent callers may race to create the same kobject, and the
+	 * loser of the race gets -EEXIST from kobject_init_and_add().
+	 */
+	guard(mutex)(&mod_kobject_mutex);
+
 	kobj = kset_find_obj(module_kset, name);
 	if (kobj)
 		return to_module_kobject(kobj);
-- 
2.34.1


-- 
Crash report (raw_report0) of the syzkaller crash this patch fixes:
---
BUG: memory leak
unreferenced object 0xffff8880188dacc0 (size 96):
  comm "syz.3.569", pid 12998, jiffies 4294992047
  hex dump (first 32 bytes):
    12 4e fe 86 ff ff ff ff c8 ac 8d 18 80 88 ff ff  .N..............
    c8 ac 8d 18 80 88 ff ff 00 00 00 00 00 00 00 00  ................
  backtrace (crc 8dccd85e):
    kmemleak_alloc_recursive home/zzzrrll/tmp/kf_src/linux-7.3-rc2/include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook home/zzzrrll/tmp/kf_src/linux-7.3-rc2/mm/slub.c:4696 [inline]
    slab_alloc_node home/zzzrrll/tmp/kf_src/linux-7.3-rc2/mm/slub.c:4996 [inline]
    __kmalloc_cache_noprof+0x1bf/0x420 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/mm/slub.c:5559
    _kmalloc_noprof home/zzzrrll/tmp/kf_src/linux-7.3-rc2/include/linux/slab.h:991 [inline]
    _kzalloc_noprof home/zzzrrll/tmp/kf_src/linux-7.3-rc2/include/linux/slab.h:1312 [inline]
    lookup_or_create_module_kobject+0x47/0x100 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/kernel/params.c:761
    module_add_driver+0x73/0x1b0 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/base/module.c:46
    bus_add_driver+0x1d9/0x340 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/base/bus.c:767
    driver_register+0xde/0x170 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/base/driver.c:174
    usb_gadget_register_driver_owner+0x50/0x140 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/usb/gadget/udc/core.c:1752
    raw_ioctl_run home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/usb/gadget/legacy/raw_gadget.c:596 [inline]
    raw_ioctl+0xa26/0x1830 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/usb/gadget/legacy/raw_gadget.c:1307
    vfs_ioctl home/zzzrrll/tmp/kf_src/linux-7.3-rc2/fs/ioctl.c:51 [inline]
    __do_sys_ioctl home/zzzrrll/tmp/kf_src/linux-7.3-rc2/fs/ioctl.c:597 [inline]
    __se_sys_ioctl+0xbc/0x130 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/fs/ioctl.c:583
    do_syscall_x64 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/arch/x86/entry/syscall_64.c:61 [inline]
    do_syscall_64+0x12b/0x350 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/arch/x86/entry/syscall_64.c:84
    entry_SYSCALL_64_after_hwframe+0x77/0x7f


<<<<<<<<<<<<<<< tail report >>>>>>>>>>>>>>>

---

Re: [PATCH v2] params: serialize lookup_or_create_module_kobject()

[Andrew Morton]

On Fri, 18 Sep 2026 10:07:12 +0000 Jiakai Xu <xujiakai24@mails.ucas.ac.cn> wrote:

> lookup_or_create_module_kobject() first looks up the module kobject with
> kset_find_obj() and, if not found, creates a new one with
> kobject_init_and_add().  The function is called at runtime from
> module_add_driver() since commit f95bbfe18512 ("drivers: base: handle
> module_kobject creation"), which means two concurrent driver
> registrations for the same built-in module name can both miss the
> lookup and race to create the same kobject.
> 
> The loser of the race gets -EEXIST from kobject_init_and_add() and its
> kobject is removed from module_kset by kobject_add_internal() before
> the failure is reported.  The error path then calls kobject_put(),
> which invokes module_kobj_release(), but that only completes
> ->kobj_completion and never frees the dynamically allocated
> module_kobject, leaking it (96 bytes) along with the object having been
> detached from the kset.
> 
> This is triggerable by unprivileged users, e.g. by concurrently issuing
> the RAW_IOCTL_INIT ioctl of the raw-gadget driver, which registers the
> "raw_gadget" driver on the gadget bus:
> 
>   sysfs: cannot create duplicate filename '/module/raw_gadget'
>   ...
>   Adding module 'raw_gadget' to sysfs failed (-17), the system may be
>   unstable.
>   ...
>   unreferenced object 0xffff8880188dacc0 (size 96):
>     backtrace:
>       lookup_or_create_module_kobject+0x47/0x100
>       module_add_driver+0x73/0x1b0
>       bus_add_driver+0x1d9/0x340
>       driver_register+0xde/0x170
> 
> Fix it by serializing the lookup and the creation with a mutex, so that
> the second caller finds the kobject created by the first one instead of
> racing with it.

You're sure we there's no race with module removal as well?

> @@ -20,6 +21,12 @@
>  /* Protects all built-in parameters, modules use their own param_lock */
>  static DEFINE_MUTEX(param_lock);
>  
> +/*
> + * Serializes module kobject lookup and creation in
> + * lookup_or_create_module_kobject()
> + */
> +static DEFINE_MUTEX(mod_kobject_mutex);

minor: this could be static inside lookup_or_create_module_kobject().

>  /* Use the module's mutex, or if built-in use the built-in mutex */
>  #ifdef CONFIG_MODULES
>  #define KPARAM_MUTEX(mod)	((mod) ? &(mod)->param_lock : &param_lock)
> @@ -754,6 +761,13 @@ lookup_or_create_module_kobject(const char *name)
>  	struct kobject *kobj;
>  	int err;
>  
> +	/*
> +	 * The lookup and the creation must be done atomically, otherwise
> +	 * concurrent callers may race to create the same kobject, and the
> +	 * loser of the race gets -EEXIST from kobject_init_and_add().
> +	 */
> +	guard(mutex)(&mod_kobject_mutex);
> +
>  	kobj = kset_find_obj(module_kset, name);
>  	if (kobj)
>  		return to_module_kobject(kobj);

Re: [PATCH v2] params: serialize lookup_or_create_module_kobject()

[Jiakai Xu]

Hi Andrew,

Thanks for the review.

> You're sure we there's no race with module removal as well?

Yes.  The two kobject populations in module_kset have different
lifecycles, and neither can race with the serialized lookup-and-create
in a harmful way:

1. The kobjects this patch serializes belong to built-in modules.
   lookup_or_create_module_kobject() has three callers:
   kernel_add_sysfs_param() and the boot cmdline paths, which are all
   __init and run before concurrency exists, and module_add_driver()
   at runtime.  Once created, a built-in module kobject is never
   deleted: nothing in this path ever calls kobject_del(), and
   module_kobj_release() only completes ->kobj_completion (it does not
   even free the object).  So there is no removal side for these
   kobjects at all.

2. Loadable modules create a separate kobject per module
   (mod->mkobj, in mod_sysfs_init()).  A loadable module cannot
   collide with the lookup either: mod_sysfs_init() itself does
   kset_find_obj() first and refuses to load when a kobject with the
   same name already exists ("module is already loaded"), and
   add_unformed_module() checks for name collisions again under
   module_mutex via module_patient_check_exists().  So a loadable
   module never registers a same-named kobject while a driver
   registration holds our mutex, and free_module()/mod_sysfs_teardown()
   only ever kobject_put() their own mkobj.

3. Even if a concurrent kobject were being removed from module_kset,
   kset_find_obj() uses kobject_get_unless_zero(), so a dying kobject
   whose reference count has already dropped to zero is simply not
   found and we would create a fresh one.

The only remaining window I can see is within kobject core itself
(between kobject_get_unless_zero() and release), which is not this
code's responsibility to serialize.

> minor: this could be static inside lookup_or_create_module_kobject().

Sure, will do in v3.

Thanks,

--
Jiakai Xu

Re: [PATCH v2] params: serialize lookup_or_create_module_kobject()

[Petr Pavlu]

On 9/18/26 12:07 PM, Jiakai Xu wrote:
> lookup_or_create_module_kobject() first looks up the module kobject with
> kset_find_obj() and, if not found, creates a new one with
> kobject_init_and_add().  The function is called at runtime from
> module_add_driver() since commit f95bbfe18512 ("drivers: base: handle
> module_kobject creation"), which means two concurrent driver
> registrations for the same built-in module name can both miss the
> lookup and race to create the same kobject.
> 
> The loser of the race gets -EEXIST from kobject_init_and_add() and its
> kobject is removed from module_kset by kobject_add_internal() before
> the failure is reported.  The error path then calls kobject_put(),
> which invokes module_kobj_release(), but that only completes
> ->kobj_completion and never frees the dynamically allocated
> module_kobject, leaking it (96 bytes) along with the object having been
> detached from the kset.

The patch fixes the module_kobject leak in this specific race condition,
but not in cases when kobject_init_and_add() (or sysfs_create_file())
fails for another reason. Do you plan to address that separately?

> 
> This is triggerable by unprivileged users, e.g. by concurrently issuing
> the RAW_IOCTL_INIT ioctl of the raw-gadget driver, which registers the
> "raw_gadget" driver on the gadget bus:

Nit: The device registration is done by the USB_RAW_IOCTL_RUN ioctl +
I believe the raw-gadget device node should default to root-only (0600).

-- 
Thanks,
Petr