Re: [PATCH] x86/boot: Reject truncated acpi_rsdp= values

[Thorsten Blum]

On Thu, Jun 18, 2026 at 11:04:12AM -0700, Borislav Petkov wrote:
> On Thu, Jun 18, 2026 at 07:59:09PM +0200, Thorsten Blum wrote:
> > On Thu, Jun 18, 2026 at 09:38:56AM -0700, Borislav Petkov wrote:
> > > On Thu, Jun 18, 2026 at 05:03:46PM +0200, Thorsten Blum wrote:
> > > > get_cmdline_acpi_rsdp() can truncate it into a different, parseable
> > > > address and use that instead.
> > > 
> > > How?
> > 
> > The buffer has 19 bytes to hold the "0x" prefix, 16 hex digits, and the
> > NUL terminator.
> > 
> > cmdline_find_option() copies only bufsize - 1 bytes, but returns the
> > full argument length. So for example:
> > 
> > 	acpi_rsdp=0x0123456789abcdefx
> > 
> > gets copied as:
> > 
> > 	0x0123456789abcdef
> > 
> > which boot_kstrtoul() parses successfully. The user supplied an invalid
> > value, but we silently use the truncated prefix as the RSDP address.
> 
> My question stands:
> 
> "Or are we protecting people from shooting themselves in foot now too?"
> 
> Especially users who should know what they're doing...
> 
> IOW, how far are we going to "protect" here?

Only far enough to avoid using a value the user didn't actually enter.

A user can still shoot themselves in the foot by using a syntactically
valid but wrong address. The check only rejects an overlong acpi_rsdp=
value after cmdline_find_option() reports that it didn't fit in the
buffer.

We already reject values that boot_kstrtoul() fails to parse; this is
the same idea: the copied string is incomplete and shouldn't be parsed.

Thanks,
Thorsten