Re: [RFC PATCH v7 05/10] trace: make the stackmap capacity settable on the kernel command line

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Booting with the parameter `ftrace_stackmap.bits` without providing a value causes a NULL pointer dereference, crashing the kernel during early boot.
--

commit 7bbdd67c3f0e40d0b1656f5e92da61a336e639f5
Author: Pengfei Li <lipengfei28@xiaomi.com>

trace: make the stackmap capacity settable on the kernel command line

This commit adds the ftrace_stackmap.bits kernel command line parameter to
allow sizing the stackmap capacity at boot. The value is clamped between
10 and 18 to bound the worst-case element pool allocations.

> diff --git a/kernel/trace/trace_stackmap.c b/kernel/trace/trace_stackmap.c
> index 439d3be9e3516..49ea403822ba3 100644
> --- a/kernel/trace/trace_stackmap.c
> +++ b/kernel/trace/trace_stackmap.c

[ ... ]

> +static int __init stackmap_bits_setup(char *str)
> +{
> +	unsigned long val;
> +
> +	if (kstrtoul(str, 0, &val))

[Severity: High]
What happens if the ftrace_stackmap.bits boot parameter is passed without an
equals sign and value?

During early boot, parse_args() uses next_arg() to parse the command line. If
the parameter is passed without a value (e.g., just ftrace_stackmap.bits),
next_arg() assigns a NULL pointer to the value string.

Does passing this NULL pointer directly to kstrtoul() cause an immediate NULL
pointer dereference and kernel panic, since kstrtoul() does not check for a
NULL pointer before dereferencing it?

> +		return -EINVAL;
> +	val = clamp_val(val, FTRACE_STACKMAP_BITS_MIN, FTRACE_STACKMAP_BITS_MAX);
> +	stackmap_map_bits = val;
> +	return 0;
> +}
> +early_param("ftrace_stackmap.bits", stackmap_bits_setup);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912083753.3426176-1-lipengfei28@xiaomi.com?part=5