kernel/git/next/linux-next.git/init/main.c, branch master

Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-09-09T11:39:28+00:00

Merge branch 'vfs.fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git

2026-09-09T10:57:03+00:00

module: rename module_blacklist to module_denylist

2026-09-09T06:32:19+00:00

To preserve the existing user-space ABI, "module_blacklist=" is kept as a legacy alias pointing to the same module_denylist variable. This patch addresses the documentation by marking "module_blacklist=" as deprecated in admin-guide/kernel-parameters.txt, and documents the new "module_denylist=" parameter. All internal symbols, such as module_is_blacklisted(), have been renamed to use "denylist" and all log messages now use "denylisted". Link: https://lore.kernel.org/20260908203230.401020-4-atomlin@atomlin.com Signed-off-by: Aaron Tomlin Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Luis Chamberalin Cc: "Masami Hiramatsu (Google)" Cc: Miguel Ojeda Cc: Peter Zijlstra Cc: Petr Pavlu Cc: Sami Tolvanen Signed-off-by: Andrew Morton

module: extend module_blacklist parameter to built-in modules

2026-09-09T06:32:19+00:00

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, built-in initcalls are executed sequentially via do_initcall_level() and do_pre_smp_initcalls(). We introduce a new wrapper function, do_one_initcall_builtin(), to cross-reference the initcall function pointer against the ".initcall.modnames" 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. Link: https://lore.kernel.org/20260908203230.401020-3-atomlin@atomlin.com Signed-off-by: Aaron Tomlin Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Luis Chamberalin Cc: "Masami Hiramatsu (Google)" Cc: Miguel Ojeda Cc: Peter Zijlstra Cc: Petr Pavlu Cc: Sami Tolvanen Signed-off-by: Andrew Morton

init/main: fix false-positive kernel panic on environment variable overwrite

2026-09-09T06:32:09+00:00

In unknown_bootoption(), the limit checking for environment variables sets panic_later *before* checking if the variable already exists in envp_init. If a user passes exactly MAX_INIT_ENVS custom variables and then overwrites the final variable by matching its key, it causes a false-positive hard panic on boot despite not actually exceeding the array bounds or increasing the total variable count. Swapping the order of these checks allows the duplicate check to break out of the loop before the panic flag is erroneously latched. To verify, boot a VM with 31 custom variables (filling the array up to its limit of 32) and then overwrite the very last variable: ENV_VARS=$(for i in {1..31}; do echo -n "var$i=$i "; done) qemu-system-x86_64 -kernel bzImage -append "$ENV_VARS var31=overwrite" Without this patch, the kernel crashes instantly with: Kernel panic - not syncing: Too many boot env vars at 'var31=overwrite' With this patch, the kernel safely overwrites the variable and boots. Link: https://lore.kernel.org/20260818045357.4123784-3-wfelipe@google.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Wilson Felipe Pereira Signed-off-by: Andrew Morton

init/main: fix off-by-one in argv_init cleanup

2026-09-09T06:32:09+00:00

Patch series "init: fix array boundary bugs in boot parameter parsing". This series fixes two distinct boundary logic edge-case bugs in `init/main.c` related to parsing boot command-line arguments and environment variables. Both bugs have been present since the early git history (Linux-2.6.12-rc2). 1. The first patch fixes an off-by-one error in `init_setup()` where the final slot of the `argv_init` array was left uncleared. This allowed a stale kernel parameter to leak into the `init` process's user-space command line if exactly `MAX_INIT_ARGS` unknown parameters were passed. 2. The second patch fixes a false-positive kernel panic in `unknown_bootoption()`. If a user filled the environment variable array up to its exact limit (32) and then attempted to overwrite the final variable, the kernel would panic before evaluating whether it was a harmless duplicate. Exact QEMU reproduction steps for both edge cases are documented inside their respective commit descriptions. This patch (of 2): When cleaning up argv_init in init_setup() and rdinit_setup(), the loop terminates one element early due to using '<' instead of '<='. Since argv_init is sized MAX_INIT_ARGS+2, index MAX_INIT_ARGS is a valid element that should be cleared to NULL. If exactly MAX_INIT_ARGS unknown arguments are passed before 'init=', the uncleared argv_init[MAX_INIT_ARGS] can act as a ghost argument to /sbin/init or cause a spurious kernel panic when later appended to. To verify the argument leak, boot a VM into a shell with 32 unknown kernel arguments, the init parameter, and 31 user arguments: STALE_ARGS=$(for i in {1..32}; do echo -n "stale$i "; done) USER_ARGS=$(for i in {1..31}; do echo -n "user$i "; done) qemu-system-x86_64 -kernel bzImage \ -append "$STALE_ARGS init=/bin/sh $USER_ARGS" Running `cat /proc/1/cmdline` inside the shell reveals that the 32nd kernel argument ('stale32') incorrectly leaked into the init process's command line. This patch zeroes the final slot, cleanly terminating the array. Link: https://lore.kernel.org/20260818045357.4123784-1-wfelipe@google.com Link: https://lore.kernel.org/20260818045357.4123784-2-wfelipe@google.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: ffdfc40976dd ("[PATCH] Add rdinit parameter to pick early userspace init") Signed-off-by: Wilson Felipe Pereira Signed-off-by: Andrew Morton

reboot: fix cad_pid use-after-free race

2026-08-31T08:25:46+00:00

cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free. kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid(). At the time this issue was reported, an unprivileged user could reach the sysctl through user and PID namespaces because cad_pid was registered in pid_table[]. Moving cad_pid back to the global reboot sysctl table corrected that namespace and permission mismatch, but did not fix the underlying lifetime race. Fix this by treating cad_pid as an RCU-protected pointer at both read sites and by waiting for a grace period before dropping the old reference on the write side. call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid() also queues pid->rcu; queueing the same rcu_head twice can corrupt the RCU callback list. Original KASAN crash stack: kernel/pid.c:545 pid_nr_ns() # reads freed pid->level kernel/pid.c:556 pid_vnr() # calls pid_nr_ns() kernel/pid.c:775 proc_do_cad_pid() # calls pid_vnr(cad_pid) Fixes: 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260717210143.4734-1-blbllhy@gmail.com/ Link: https://lore.kernel.org/all/alz5ZYLE4kaq_v2P@redhat.com/ Link: https://lore.kernel.org/all/al4ICz9biJKtdZc4@redhat.com/ Suggested-by: Mateusz Guzik Suggested-by: Bradley Morgan Suggested-by: Oleg Nesterov Suggested-by: Eric W. Biederman Suggested-by: Pavel Tikhomirov Cc: stable@vger.kernel.org Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260814040944.16561-1-blbllhy@gmail.com Reviewed-by: Bradley Morgan Reviewed-by: Oleg Nesterov Reviewed-by: Pavel Tikhomirov Signed-off-by: Christian Brauner (Amutable)

Merge tag 'bootconfig-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

2026-08-25T15:59:09+00:00

Pull bootconfig updates from Masami Hiramatsu: - Support build-time command line building for embedded bootconfig - Fix xbc_snprint_cmdline() to render descendant keys when the root has both a value and subkeys, and treats empty subtrees correctly. - Add build-time pipeline using tools/bootconfig -C to render the embedded bootconfig "kernel" subtree into .init.rodata as a cmdline string. - Clean build-time tools/bootconfig from make clean - Add helper to prepend embedded bootconfig cmdline into boot_command_line early before parse_early_param() - Wire early prepend helper in x86 setup_arch() so early_param handlers see values from the embedded bootconfig (currently x86 only) - Avoid duplicating "kernel" keys in setup_boot_config() - Refactor setup_boot_config() to share bootconfig_cmdline_requested() - Document CONFIG_CMDLINE_FROM_BOOTCONFIG usage, requirements, and precedence * tag 'bootconfig-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: init/main.c: use bootconfig_cmdline_requested() for the runtime opt-in bootconfig: skip runtime kernel.* render once prepended early x86/setup: prepend embedded bootconfig cmdline before parse_early_param Documentation: bootconfig: document build-time cmdline rendering bootconfig: add xbc_prepend_embedded_cmdline() helper bootconfig: clean build-time tools/bootconfig from make clean bootconfig: render embedded bootconfig as a kernel cmdline at build time bootconfig: render descendant keys when xbc_snprint_cmdline() root has a value

init/main.c: use bootconfig_cmdline_requested() for the runtime opt-in

2026-07-02T12:15:46+00:00

setup_boot_config() open-coded the same "is bootconfig requested on the kernel command line?" check that setup_arch() performs via the shared bootconfig_cmdline_requested() helper. Switch it to the helper so the early (setup_arch) and late (setup_boot_config) paths use one parser and cannot disagree on what counts as opt-in. The helper also reports the offset of the init arguments following a "--" separator, which is exactly what initargs_offs needs, so the local parse_args() call, its bootconfig_params() callback and the tmp_cmdline copy are removed. No functional change intended. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-9-24ab72139c29@debian.org/ Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google)

bootconfig: skip runtime kernel.* render once prepended early

2026-07-02T12:15:46+00:00

setup_boot_config() folds the embedded bootconfig "kernel" subtree into the command line via xbc_make_cmdline("kernel"). A subsequent patch lets an architecture prepend the build-time-rendered embedded "kernel" keys to boot_command_line early in setup_arch(); rendering them again here would then duplicate every key in saved_command_line and make accumulating handlers (console=, earlycon=, ...) re-register the same value. Track whether the bootconfig data came from the embedded source (from_embedded) and skip the runtime render only when the early prepend actually happened, as reported by xbc_embedded_cmdline_applied(). On architectures that do not select ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG that helper is a stub returning false, so this path is unchanged and the embedded "kernel" keys still reach the cmdline via the runtime parser exactly as before. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-8-24ab72139c29@debian.org/ Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google)