public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Li Chen <me@linux.beauty>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	 Mike Rapoport <rppt@kernel.org>,
	 Pratyush Yadav <pratyush@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] liveupdate: sanitize incoming session count
Date: Tue, 10 Feb 2026 14:26:46 +0100	[thread overview]
Message-ID: <2vxzjywku3u1.fsf@kernel.org> (raw)
In-Reply-To: <20260130084615.357435-1-me@linux.beauty> (Li Chen's message of "Fri, 30 Jan 2026 16:46:15 +0800")

Hi Li,

On Fri, Jan 30 2026, Li Chen wrote:

> luo_session_deserialize() iterates incoming sessions using
> luo_session_header_ser::count. The header physical address is provided by
> the previous kernel via the KHO FDT node.
>
> If the header is corrupted, count may become arbitrarily large and the new
> kernel can read past the preserved session array (sh->ser[i]). This is an
> OOB read that can crash or hang early boot.
>
> This can happen if the FDT node is corrupted or mis-parsed and points to a
> wrong header address, if stale/incompatible handover data is interpreted
> with the wrong layout, or if the preserved region is scribbled by memory
> corruption or DMA after kexec.

If the header is corrupted, won't the FDT magic checks fail when doing
any of the FDT operations like getting the compatible? Or perhaps we
should call fdt_check_header() in luo_early_startup()?

I think the sanity check might still be a useful thing, but I'd like to
clarify _why_ we are doing this.

>
> Clamp the incoming count to LUO_SESSION_MAX before iterating.
>
> Signed-off-by: Li Chen <me@linux.beauty>
[...]

-- 
Regards,
Pratyush Yadav

      reply	other threads:[~2026-02-10 13:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30  8:46 [PATCH v1] liveupdate: sanitize incoming session count Li Chen
2026-02-10 13:26 ` Pratyush Yadav [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=2vxzjywku3u1.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@linux.beauty \
    --cc=pasha.tatashin@soleen.com \
    --cc=rppt@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