From: Mike Rapoport <rppt@kernel.org>
To: Marco Elver <elver@google.com>
Cc: Alexander Graf <graf@amazon.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com
Subject: Re: [PATCH] kho: validate order in deserialize_bitmap()
Date: Sun, 15 Feb 2026 08:47:21 +0200 [thread overview]
Message-ID: <aZFr-TvaWn-KbA1u@kernel.org> (raw)
In-Reply-To: <20260214010013.3027519-1-elver@google.com>
Hi Marco,
On Sat, Feb 14, 2026 at 01:57:51AM +0100, Marco Elver wrote:
> The function deserialize_bitmap() calculates the reservation size using:
>
> int sz = 1 << (order + PAGE_SHIFT);
>
> If a corrupted KHO image provides an order >= 20 (on systems with 4KB
> pages), the shift amount becomes >= 32, which overflows the 32-bit
> integer. This results in a zero-size memory reservation.
>
> Furthermore, the physical address calculation:
>
> phys_addr_t phys = elm->phys_start + (bit << (order + PAGE_SHIFT));
>
> can also overflow and wrap around if the order is large. This allows a
> corrupt KHO image to cause out-of-bounds updates to page->private of
> arbitrary physical pages during early boot.
>
> Fix this by adding a bounds check for the order field.
>
> Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation")
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> kernel/liveupdate/kexec_handover.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index b851b09a8e99..ec353e4b68a6 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -463,6 +463,11 @@ static void __init deserialize_bitmap(unsigned int order,
> struct kho_mem_phys_bits *bitmap = KHOSER_LOAD_PTR(elm->bitmap);
> unsigned long bit;
>
> + if (order > MAX_PAGE_ORDER) {
Preserved order can be larger than MAX_PAGE_ORDER.
Let's make 'sz' unsigned long and add checks that calculations won't
overflow.
> + pr_warn("invalid order %u for preserved bitmap\n", order);
> + return;
> + }
> +
> for_each_set_bit(bit, bitmap->preserve, PRESERVE_BITS) {
> int sz = 1 << (order + PAGE_SHIFT);
> phys_addr_t phys =
> --
> 2.53.0.335.g19a08e0c02-goog
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2026-02-15 6:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 0:57 [PATCH] kho: validate order in deserialize_bitmap() Marco Elver
2026-02-15 6:47 ` Mike Rapoport [this message]
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=aZFr-TvaWn-KbA1u@kernel.org \
--to=rppt@kernel.org \
--cc=elver@google.com \
--cc=graf@amazon.com \
--cc=kasan-dev@googlegroups.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@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.