From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B63B526ED3A for ; Tue, 10 Feb 2026 13:26:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770730009; cv=none; b=GQ93i33Uqh4nMCkRxT9J20ic5TtwuX29KrdLgCdYjKy1EImHKq7sO4S91KLqXkl5GkqI23iglQB2YRPjiIX6hn4y7cF/yNLiwTA0zlTzTHj/MkSoH8+6r6j5y0UAU0TNImI6thEv/nqrNk1x4M6mCOsrU9FN7LUWEa4EcL5iYy0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770730009; c=relaxed/simple; bh=W3CeY1kW2xU3f9TOSBHhGwsbqhTuFt1wK83ESs0sqMk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=fAVlZeYLNmnEie5MNFsxT456eWD+X68UZUZeJVagbt88BOs8u8o89Z6qgaRhmIrjg+9EvugrICKt4h/AUcEn/pcgDMP+quQFrkfubzTUy9RQ3hovid5380YBls/C8CZsvrJydfPp4pCWgecGfvoU/epMe3SVPbvUs1+8iYIxXOs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DIiClx9j; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DIiClx9j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E1A3C116C6; Tue, 10 Feb 2026 13:26:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770730009; bh=W3CeY1kW2xU3f9TOSBHhGwsbqhTuFt1wK83ESs0sqMk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DIiClx9jQrv9s5wkf4yfOHl/UaCGsFpzHxCpluCflFZ5WsbUpLO/FIgtU25feL2dI KQFeVwKjK7NWuXvg/RwUSX9n0bvMdisn7CcsxBkxXuBZ4PcASsY4P4iPhOwovmrjvD AyYfMiG15pMJKzlpGo+Epm2MGnp6THii0RpwD6LziKM6FQKvhzLpqDDh8VsIHF2BQq ufw+nAxRKHst7qmNu9wTF3dPjXmoY3iOXbDdwsTc7lo7wZIUljaY9/UfRGK1s4wYjZ jKeyunCBhB0tKYO2pu2QBkxQFuXSw7KWIv3PU3Ik3osFgUq/Pu74+E4t+N5jKwNplI tOtcLFZvRZ6/g== From: Pratyush Yadav To: Li Chen Cc: Pasha Tatashin , Mike Rapoport , Pratyush Yadav , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] liveupdate: sanitize incoming session count In-Reply-To: <20260130084615.357435-1-me@linux.beauty> (Li Chen's message of "Fri, 30 Jan 2026 16:46:15 +0800") References: <20260130084615.357435-1-me@linux.beauty> Date: Tue, 10 Feb 2026 14:26:46 +0100 Message-ID: <2vxzjywku3u1.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain 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 [...] -- Regards, Pratyush Yadav