summaryrefslogtreecommitdiff
path: root/kernel/module/dups.c
AgeCommit message (Collapse)AuthorFilesLines
2026-08-06module/dups: Clean up includesPetr Pavlu1-20/+12
The kernel/module/dups.c file relies on the following definitions and associated functions: * module_param() -> linux/moduleparam.h, * DEFINE_MUTEX() -> linux/mutex.h, * LIST_HEAD(), list_for_each_entry(), ... -> linux/list.h, * refcount_t, refcount_inc(), ... -> linux/refcount.h, * MODULE_NAME_LEN -> linux/module.h, * completion, complete_all(), ... -> linux/completion.h, * delayed_work, work_struct, ... -> linux/workqueue.h, * lockdep_assert_held() -> linux/lockdep.h, * strcmp(), memcpy() -> linux/string.h, * container_of() -> linux/container_of.h, * DEFINE_FREE(), __free(), scoped_guard() -> linux/cleanup.h, * kzalloc_obj(), kfree() -> linux/slab.h, * pr_debug(), pr_warn() -> linux/printk.h, * WARN() -> linux/bug.h, * TASK_KILLABLE -> linux/sched.h, * HZ -> linux/param.h. Update the file's include list accordingly. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-08-06module/dups: Use strcmp() to compare module namesPetr Pavlu1-4/+2
Use strcmp() instead of strlen()+memcmp() to compare module names in kmod_dup_request_lookup(), since all strings are NUL-terminated. Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-08-06module/dups: Use scope-based cleanup helpersPetr Pavlu1-33/+23
Use scope-based cleanup helpers for kmod_dup_mutex and kmod_req to shorten the code and to clarify where the lock is taken in kmod_dup_request_exists_wait(). Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-08-06module/dups: Avoid unnecessary kmod_dup_req allocationsPetr Pavlu1-16/+22
The kmod dups code preallocates kmod_dup_req before taking kmod_dup_mutex to avoid allocating memory while holding the lock. This provides little benefit, since the allocation is fast and can safely be done under the lock. On the other hand, it leads to unnecessary allocations when the request turns out to be a duplicate and slightly complicates the code. Allocate kmod_dup_req only when needed and introduce a helper function alloc_kmod_req() to initialize the structure. Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-08-06module/dups: Fix use-after-free in kmod_dup_req lifetime handlingPetr Pavlu1-16/+40
The kmod dups code uses RCU to ensure that a kmod_dup_req instance is freed only after it is no longer referenced. When releasing an instance, the kmod_dup_request_delete() function removes the kmod_dup_req from the dup_kmod_reqs list, waits via synchronize_rcu() and finally frees it. However, this doesn't work correctly because parallel users referencing the instance in kmod_dup_request_exists_wait() don't enter an RCU read-side critical section. This can result in a use-after-free. The kmod_dup_request_exists_wait() function may need to hold a valid reference to a kmod_dup_req instance across a blocking wait until the corresponding modprobe command completes. This makes it unsuitable for RCU. Fix the issue by changing the lifecycle management of kmod_dup_req to use reference counting. Fixes: 8660484ed1cf ("module: add debugging auto-load duplicate module support") Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-08-06module/dups: Inform duplicate requests about the result directlyPetr Pavlu1-34/+9
When kmod_dup_request_announce() announces the completion of a request_module() call to duplicate waiters, it queues a work item to invoke kmod_dup_request_complete(), and only that function calls complete_all(). This adds an arbitrary delay that is unnecessary and provides little benefit. Call complete_all() directly from kmod_dup_request_announce() instead. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-08-06module: use strscpy() to copy module names in stats and dup trackingNaveen Kumar Chaudhary1-1/+1
Both try_add_failed_module() and kmod_dup_request_exists_wait() use memcpy() with strlen() to copy module names into fixed-size char[MODULE_NAME_LEN] buffers. Neither performs a bounds check on the copy. Current callers always pass names originating from mod->name (itself char[MODULE_NAME_LEN]), so this is not exploitable today. However both functions accept a plain const char * with no documented length contract, making them latent buffer overflows if a future caller passes a longer string. Replace memcpy() with strscpy() in both sites, which bounds the copy to MODULE_NAME_LEN and always NUL-terminates. Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds1-1/+1
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook1-1/+1
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2025-12-22module: replace use of system_wq with system_dfl_wqMarco Crivellari1-2/+2
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Switch to using system_dfl_wq, the new unbound workqueue, because the users do not benefit from a per-cpu workqueue. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2024-10-07remove pointless includes of <linux/fdtable.h>Al Viro1-1/+0
some of those used to be needed, some had been cargo-culted for no reason... Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2023-12-19module: Remove redundant TASK_UNINTERRUPTIBLEKevin Hao1-1/+1
TASK_KILLABLE already includes TASK_UNINTERRUPTIBLE, so there is no need to add a separate TASK_UNINTERRUPTIBLE. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-05-02module: include internal.h in module/dups.cArnd Bergmann1-0/+2
Two newly introduced functions are declared in a header that is not included before the definition, causing a warning with sparse or 'make W=1': kernel/module/dups.c:118:6: error: no previous prototype for 'kmod_dup_request_exists_wait' [-Werror=missing-prototypes] 118 | bool kmod_dup_request_exists_wait(char *module_name, bool wait, int *dup_ret) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel/module/dups.c:220:6: error: no previous prototype for 'kmod_dup_request_announce' [-Werror=missing-prototypes] 220 | void kmod_dup_request_announce(char *module_name, int ret) | ^~~~~~~~~~~~~~~~~~~~~~~~~ Add an explicit include to ensure the prototypes match. Fixes: 8660484ed1cf ("module: add debugging auto-load duplicate module support") Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304141440.DYO4NAzp-lkp@intel.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-04-19module: add debugging auto-load duplicate module supportLuis Chamberlain1-0/+246
The finit_module() system call can in the worst case use up to more than twice of a module's size in virtual memory. Duplicate finit_module() system calls are non fatal, however they unnecessarily strain virtual memory during bootup and in the worst case can cause a system to fail to boot. This is only known to currently be an issue on systems with larger number of CPUs. To help debug this situation we need to consider the different sources for finit_module(). Requests from the kernel that rely on module auto-loading, ie, the kernel's *request_module() API, are one source of calls. Although modprobe checks to see if a module is already loaded prior to calling finit_module() there is a small race possible allowing userspace to trigger multiple modprobe calls racing against modprobe and this not seeing the module yet loaded. This adds debugging support to the kernel module auto-loader (*request_module() calls) to easily detect duplicate module requests. To aid with possible bootup failure issues incurred by this, it will converge duplicates requests to a single request. This avoids any possible strain on virtual memory during bootup which could be incurred by duplicate module autoloading requests. Folks debugging virtual memory abuse on bootup can and should enable this to see what pr_warn()s come on, to see if module auto-loading is to blame for their wores. If they see duplicates they can further debug this by enabling the module.enable_dups_trace kernel parameter or by enabling CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS_TRACE. Current evidence seems to point to only a few duplicates for module auto-loading. And so the source for other duplicates creating heavy virtual memory pressure due to larger number of CPUs should becoming from another place (likely udev). Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>