Re: [PATCH v5 1/2] module: Extend module_blacklist parameter to built-in modules

On Sat, Jul 18, 2026 at 01:13:49AM -0400, Aaron Tomlin wrote:

Currently, the "module_blacklist=" command-line parameter only applies
to loadable modules. If a module is built-in, the parameter is silently
ignored. This patch extends the blacklisting functionality to built-in
modules by intercepting their initialisation routines during early boot.

To achieve this, we introduce a new ".initcall.modnames" memory section.
For each built-in module, we use a standard C structure (i.e., struct
initcall_modname) to map its initcall function pointer to its associated
KBUILD_MODNAME string. This mapping is restricted only to files implementing
built-in modules via module_init() to avoid mapping core kernel subsystems
and save memory.

During boot, do_one_initcall() cross-references the initcall function
pointer against this table. If a match is found and the module is
present in the blacklist, the initcall is skipped.

To make the blacklist functional on monolithic kernels, the command-line
parameter parsing and the module_is_blacklisted() lookup function are
decoupled from the loadable module subsystem and moved to init/main.c.
This enables "module_blacklist=" to intercept built-in modules even on
kernels built with CONFIG_MODULES=n.

Hi Arnd, Luis, Petr, Daniel, Sami,

Please ignore this iteration.

I forgot to update Documentation/admin-guide/kernel-parameters.txt to
properly document the new "module_denylist=" parameter while marking
"module_blacklist=" as deprecated. Furthermore, I will rename
module_blacklist to module_denylist in init/main.c, provide a legacy
parameter alias, and update the log message to say "denylisted".

Finally, to address the race condition and runtime
vulnerability reported by Sashiko [1], I will remove the temporal check
entirely and embed the boot-time blacklist check inside the a new
do_one_initcall_builtin() __init wrapper function. This should ensure the
metadata lookup logic is exclusively invoked during early boot.
Consequently, since this wrapper is freed post-boot, it is physically
impossible for loadable modules or userspace actors to execute it,
completely closing the vulnerability and race conditions.


[1]: https://sashiko.dev/#/patchset/20260718051350.344772-1-atomlin%40atomlin.com

Kind regards,
-- 
Aaron Tomlin