All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wilson Felipe Pereira" <wfelipe@google.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
	linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH 2/3] arch: use CONFIG_COMMAND_LINE_SIZE across all architectures
Date: Thu, 06 Aug 2026 06:25:57 +0000	[thread overview]
Message-ID: <20260806062558.68DD01F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806061429.474992-3-wfelipe@google.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] RISC-V default command line size is silently truncated from 2048 to 1024 bytes.
- [High] Exposing COMMAND_LINE_SIZE to Kconfig allows deterministic stack exhaustion in the ARM boot decompressor.
- [High] Configurable COMMAND_LINE_SIZE causes stack exhaustion during early boot on m68k Atari.
--

--- Patch [2]: [PATCH 2/3] arch: use CONFIG_COMMAND_LINE_SIZE across all architectures ---
commit 86e4b8b798d614166a3d212659ea7796c8a7ee99
Author: Wilson Felipe Pereira <wfelipe@google.com>

arch: use CONFIG_COMMAND_LINE_SIZE across all architectures

This commit updates every architecture's setup.h to define COMMAND_LINE_SIZE
using CONFIG_COMMAND_LINE_SIZE for the kernel. The historical hardcoded
defaults are retained in user-space API headers by wrapping the definition
in an #ifdef __KERNEL__ guard.

> diff --git a/arch/arm/include/uapi/asm/setup.h b/arch/arm/include/uapi/asm/setup.h
> index 8e50e034fec73..4aa93558af1e7 100644
> --- a/arch/arm/include/uapi/asm/setup.h
> +++ b/arch/arm/include/uapi/asm/setup.h
> @@ -17,7 +17,11 @@
>  
>  #include <linux/types.h>
>  
> -#define COMMAND_LINE_SIZE 1024
> +#ifdef __KERNEL__
> +#define COMMAND_LINE_SIZE	CONFIG_COMMAND_LINE_SIZE
> +#else
> +#define COMMAND_LINE_SIZE	1024
> +#endif

[Severity: High]
Does exposing COMMAND_LINE_SIZE to Kconfig allow deterministic stack exhaustion
in the ARM boot decompressor?

The ARM boot decompressor uses a fixed 4KB stack (.L_user_stack in
arch/arm/boot/compressed/head.S), and merge_fdt_bootargs() allocates:

arch/arm/boot/compressed/atags_to_fdt.c:merge_fdt_bootargs() {
    ...
	char cmdline[COMMAND_LINE_SIZE];
    ...
}

If a user configures CONFIG_COMMAND_LINE_SIZE to a value larger than ~3KB,
will this stack allocation deterministically crash on boot?

[ ... ]

> diff --git a/arch/m68k/include/uapi/asm/setup.h b/arch/m68k/include/uapi/asm/setup.h
> index 25fe26d5597cc..2d5b24a5345f9 100644
> --- a/arch/m68k/include/uapi/asm/setup.h
> +++ b/arch/m68k/include/uapi/asm/setup.h
> @@ -12,6 +12,10 @@
>  #ifndef _UAPI_M68K_SETUP_H
>  #define _UAPI_M68K_SETUP_H
>  
> -#define COMMAND_LINE_SIZE 256
> +#ifdef __KERNEL__
> +#define COMMAND_LINE_SIZE	CONFIG_COMMAND_LINE_SIZE
> +#else
> +#define COMMAND_LINE_SIZE	256
> +#endif

[Severity: High]
Can a configurable COMMAND_LINE_SIZE cause stack exhaustion during early boot
on m68k Atari?

atari_switches_setup() allocates an array locally on the limited kernel stack:

arch/m68k/atari/config.c:atari_switches_setup() {
    ...
	char switches[COMMAND_LINE_SIZE];
    ...
}

Will tying this to an unbound Kconfig option introduce deterministic stack
exhaustion on boot for m68k Atari kernels?

[ ... ]

> diff --git a/arch/riscv/include/uapi/asm/setup.h b/arch/riscv/include/uapi/asm/setup.h
> index eb4f0209c6960..a6c1f4b0987e3 100644
> --- a/arch/riscv/include/uapi/asm/setup.h
> +++ b/arch/riscv/include/uapi/asm/setup.h
> @@ -3,6 +3,10 @@
>  #ifndef _UAPI_ASM_RISCV_SETUP_H
>  #define _UAPI_ASM_RISCV_SETUP_H
>  
> +#ifdef __KERNEL__
> +#define COMMAND_LINE_SIZE	CONFIG_COMMAND_LINE_SIZE
> +#else
>  #define COMMAND_LINE_SIZE	2048
> +#endif

[Severity: High]
Is the RISC-V default command line size silently truncated from 2048 to 1024
bytes?

The Kconfig default in init/Kconfig erroneously groups RISC-V with ARM and
PARISC (1024):

init/Kconfig:
	default 1024 if ARM || PARISC || RISCV

By replacing the kernel definition with CONFIG_COMMAND_LINE_SIZE here, does
this create a dangerous discrepancy where userspace headers claim the limit
is 2048, while the kernel internally enforces 1024 and truncates existing
boot configurations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806061429.474992-1-wfelipe@google.com?part=2

  reply	other threads:[~2026-08-06  6:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06  6:14 [PATCH 0/3] init/Kconfig: generalize config COMMAND_LINE_SIZE Wilson Felipe Pereira
2026-08-06  6:14 ` Wilson Felipe Pereira
2026-08-06  6:14 ` [PATCH 1/3] init/Kconfig: generalize config COMMAND_LINE_SIZE to all architectures Wilson Felipe Pereira
2026-08-06  6:14   ` Wilson Felipe Pereira
2026-08-06  6:26   ` sashiko-bot
2026-08-06  6:14 ` [PATCH 2/3] arch: use CONFIG_COMMAND_LINE_SIZE across " Wilson Felipe Pereira
2026-08-06  6:14   ` Wilson Felipe Pereira
2026-08-06  6:25   ` sashiko-bot [this message]
2026-08-06  6:14 ` [PATCH 3/3] init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable Wilson Felipe Pereira
2026-08-06  6:14   ` Wilson Felipe Pereira
2026-08-06  6:29   ` sashiko-bot
2026-08-06 22:57 ` [PATCH 0/3] init/Kconfig: generalize config COMMAND_LINE_SIZE Andrew Morton
2026-08-06 22:57   ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2026-08-06  6:05 Wilson Felipe Pereira
2026-08-06  6:05 ` [PATCH 2/3] arch: use CONFIG_COMMAND_LINE_SIZE across all architectures Wilson Felipe Pereira
2026-08-06  6:05   ` Wilson Felipe Pereira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260806062558.68DD01F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wfelipe@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.