Re: [PATCH 3/3] init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] init_setup() and rdinit_setup() fail to clear argv_init[MAX_INIT_ARGS], leading to a ghost argument or spurious kernel panic.
--

--- Patch [3]: [PATCH 3/3] init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable ---
commit 40d27a1b9f7dbca831686327245c33052b28fb18
Author: Wilson Felipe Pereira <[email protected]>

init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable

This commit makes the INIT_ENV_ARG_LIMIT Kconfig symbol user-configurable
by adding a prompt string and a valid range. This allows users to increase
the maximum number of kernel command-line arguments passed to init beyond
the default.

> diff --git a/init/Kconfig b/init/Kconfig
> index c581817966ee2..a77a2c33c319c 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -228,9 +228,10 @@ config BROKEN_ON_SMP
>  	default y
>  
>  config INIT_ENV_ARG_LIMIT
> -	int
> +	int "Maximum number of kernel command line arguments"
>  	default 32 if !UML
>  	default 128 if UML
> +	range 32 4096

[Severity: High]
This is a pre-existing issue, but could making this limit configurable 
expose a bug in init_setup() and rdinit_setup() where they fail to clear 
the last element of argv_init?

Looking at init_setup() in init/main.c:

init/main.c:init_setup() {
    ...
	for (i = 1; i < MAX_INIT_ARGS; i++)
		argv_init[i] = NULL;
    ...
}

And similarly in rdinit_setup():

init/main.c:rdinit_setup() {
    ...
	for (i = 1; i < MAX_INIT_ARGS; i++)
		argv_init[i] = NULL;
    ...
}

Since argv_init is sized MAX_INIT_ARGS + 2, if the boot command line includes 
exactly MAX_INIT_ARGS unknown arguments before 'init=', they populate 
argv_init[1] through argv_init[MAX_INIT_ARGS]. The loop in init_setup() stops 
at MAX_INIT_ARGS - 1, leaving argv_init[MAX_INIT_ARGS] populated with a stale 
argument.

If the boot command line then provides MAX_INIT_ARGS - 1 arguments after 
'init=', they fill indices 1 to MAX_INIT_ARGS - 1. This makes the uncleared 
argv_init[MAX_INIT_ARGS] contiguous, which could cause kernel_execve to 
pass it to init as a ghost argument. 

Alternatively, if exactly MAX_INIT_ARGS arguments are provided after 'init=',
could the argument checking loop evaluate argv_init[MAX_INIT_ARGS] as true,
set panic_later, and cause a spurious boot panic?

>  	help
>  	  Maximum of each of the number of arguments and environment
>  	  variables passed to init from the kernel command line.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3