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 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.