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

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git

2026-09-07T13:27:31+00:00

# Conflicts: # include/linux/ns/ns_common_types.h

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

2026-09-07T12:11:46+00:00

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

2026-09-07T11:11:53+00:00

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

2026-09-06T03:23:23+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-06T03:23:23+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

init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable

2026-09-06T03:23:22+00:00

Patch series "init, arch: make command line size and init arg limit configurable", v2. This patch series promotes COMMAND_LINE_SIZE from arch/s390/Kconfig to init/Kconfig to be generally available to other architectures. In some use cases, such as netboot kernels, rootfs configurations, larger initramfs setups, require larger sizes. While for embedded workloads, it can be reduced to save memory. Since COMMAND_LINE_SIZE can be larger, it also makes sense to allow INIT_ENV_ARG_LIMIT to be configured. This patch (of 2): INIT_ENV_ARG_LIMIT is defined without a prompt string (`int`), making it a hidden Kconfig symbol that defaults to 32 (or 128 for UML) and cannot be configured in `make menuconfig`. Now that CONFIG_COMMAND_LINE_SIZE is configurable across all architectures, users who select larger kernel command lines (e.g., 4096 bytes) may pass more than 32 command-line arguments or environment variables (`foo=bar`) to `/sbin/init`. If INIT_ENV_ARG_LIMIT remains hardcoded at 32, any argument after the 32nd sets the panic_later flag and causes a hard kernel panic on boot. Add a prompt string ("Maximum number of kernel command line arguments") and a `range 32 4096` to `config INIT_ENV_ARG_LIMIT` so that users can configure their init argument and environment variable limit when needed, while preserving the existing default of 32 for standard builds. Link: https://lore.kernel.org/20260818231646.804507-1-wfelipe@google.com Link: https://lore.kernel.org/20260818231646.804507-3-wfelipe@google.com Signed-off-by: Maciej Żenczykowski Signed-off-by: Wilson Felipe Pereira Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Arnd Bergmann Cc: Christian Borntraeger Cc: Heiko Carstens Cc: Palmer Dabbelt Cc: Sven Schnelle Cc: Vasily Gorbik Signed-off-by: Andrew Morton

init, arch: make CONFIG_COMMAND_LINE_SIZE globally configurable

2026-09-06T03:23:22+00:00

Currently, s390 has the ability to configure the maximum kernel command line size via Kconfig (CONFIG_COMMAND_LINE_SIZE). Other architectures define a hardcoded COMMAND_LINE_SIZE macro in their setup.h headers. In some use cases, such as netboot kernels, rootfs configurations, or larger initramfs setups, a larger command line size is required. While for embedded workloads, it can be reduced to save memory. Move CONFIG_COMMAND_LINE_SIZE out of arch/s390/Kconfig and into init/Kconfig under General setup, and update every architecture's setup.h header to define COMMAND_LINE_SIZE as CONFIG_COMMAND_LINE_SIZE. For user-space API (uapi) headers, wrap the definition in an `#ifdef __KERNEL__` guard and retain the historical hardcoded default in the `#else` block. When user-space headers are installed via `make headers_install`, unifdef strips out the kernel section, ensuring the same value as before for user-space applications including ``. For S390, the range is kept the same, but other architectures have varying constraints. S390 requires a minimum of 896 bytes to protect legacy bootloaders from overwriting the .text section. ARM, M68K, and NIOS2 allocate the command line directly on severely constrained decompressor stacks, so their ranges are strictly capped at 2048 bytes to prevent deterministic stack exhaustion and boot panics. PowerPC (PPC) boot wrappers silently truncate arguments past 2048 bytes, so it is also capped at 2048 to prevent silent parameter loss. The SuperH (SUPERH) boot parameter page allocates exactly PAGE_SIZE (typically 4096 bytes), and placing a 4096-byte command line starting at offset 256 would cause strscpy() to read out of bounds; it is capped at 3840 bytes. Alpha physically limits its boot parameter block to 256 bytes, so its limit is strictly locked to 256. All other architectures are capped at 4096 bytes to prevent unreasonable allocations. Link: https://lore.kernel.org/20260818231646.804507-2-wfelipe@google.com Signed-off-by: Maciej Żenczykowski Signed-off-by: Wilson Felipe Pereira Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Arnd Bergmann Cc: Christian Borntraeger Cc: Heiko Carstens Cc: Palmer Dabbelt Cc: Sven Schnelle Cc: Vasily Gorbik Signed-off-by: Andrew Morton

init: simplify early_hostname()

2026-09-06T03:23:21+00:00

Inline the strscpy() check and remove the redundant arglen variable. Use %zu to format the unsigned maxlen argument and add a newline after the truncation warning. Link: https://lore.kernel.org/20260828174337.609333-2-blum@kernel.org Signed-off-by: Thorsten Blum Signed-off-by: Andrew Morton

init: fix early boot crash with bare hostname parameter

2026-09-06T03:23:17+00:00

When a bare hostname parameter is specified on the kernel command line without the '=' separator, early parameter parsing passes NULL to early_hostname(), which dereferences it in strscpy() and can crash the system during early boot. Reject NULL values in early_hostname() and return -EINVAL instead. Link: https://lore.kernel.org/20260826100904.296151-2-blum@kernel.org Fixes: 5a704629f2c1 ("init: add "hostname" kernel parameter") Signed-off-by: Thorsten Blum Cc: Dan Moulding Cc: Signed-off-by: Andrew Morton

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook