From: Thorsten Blum <thorsten.blum@linux.dev>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/boot: Reject truncated acpi_rsdp= values
Date: Fri, 19 Jun 2026 03:00:54 +0200 [thread overview]
Message-ID: <ajSUxr0dfJmQFqkP@linux.dev> (raw)
In-Reply-To: <20260618193409.GFajRIMdiw-2WGJRKN@fat_crate.local>
On Thu, Jun 18, 2026 at 12:34:09PM -0700, Borislav Petkov wrote:
> On Thu, Jun 18, 2026 at 08:57:56PM +0200, Thorsten Blum wrote:
> > Only far enough to avoid using a value the user didn't actually enter.
>
> But the user did enter it.
>
> And nothing in there tells her/him that they entered a wrong value. Only that
> the value she entered magically turned into a 0.
>
> So how is that helping said user fix the input?
>
> And is there a real use case you're fixing here or is this something
> hypothetical that *might* happen?
>
> > 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.
>
> My question still stands paraphrazed: what *actual*, real use case are you
> fixing here?
>
> And how does your fix make anything better?
Without this patch, the decompressor acts on a truncated address. The
result is undefined and crashed my setup during early boot (an internal
broken script surfaced this).
With this patch, a user at least has a chance to see the main kernel's
log message:
[ 0.000000] Malformed early option 'acpi_rsdp'
You can reproduce this with QEMU using the malformed example from
before:
acpi_rsdp=0x0123456789abcdefx
next prev parent reply other threads:[~2026-06-19 1:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 13:04 [PATCH] x86/boot: Reject truncated acpi_rsdp= values Thorsten Blum
2026-06-18 4:54 ` Borislav Petkov
2026-06-18 15:03 ` Thorsten Blum
2026-06-18 16:38 ` Borislav Petkov
2026-06-18 17:59 ` Thorsten Blum
2026-06-18 18:04 ` Borislav Petkov
2026-06-18 18:57 ` Thorsten Blum
2026-06-18 19:34 ` Borislav Petkov
2026-06-19 1:00 ` Thorsten Blum [this message]
2026-06-19 2:48 ` Borislav Petkov
2026-06-19 7:57 ` Thorsten Blum
2026-06-19 20:24 ` Borislav Petkov
2026-06-19 21:43 ` Thorsten Blum
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=ajSUxr0dfJmQFqkP@linux.dev \
--to=thorsten.blum@linux.dev \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox