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 C6F3E1EEA54 for ; Tue, 31 Mar 2026 09:40:30 +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=1774950030; cv=none; b=ghVWVX6ycUxi1WxlDVTRsBeZXUD7y775/3C5EbvFIt6YMsXdaBJljbCcFNlqoIF5RYvDR+VGNCWI7GYwE5E550+h41/n/rI+hjqx/7ZZG/sCYb54omdNR0rL/m81mU1BT+lxcfrRYD2Gi9y0IUJw9WH36RZP7lwySZKYxsT7mw4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774950030; c=relaxed/simple; bh=T7KhY3GM2hmdjQuBjDcNWz4pOtoqYT5vZ5McUEpAqqo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=idmjJ/X+YaIO6YV6/CmJobct5xt7mlY8df1/u2pVAmUPKpgLW+rGTvhCDTWdfoQ7iNpb6OzIJUaPzseYSUTy/q0Egczvl4pwLQeu4KDoUH7ncwojstPrZzihYDJF6N//q1TtK310e0MT8QkxZ+CfraGuXuVISL3eRqNX9169UUY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r7HQNcqp; 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="r7HQNcqp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5F1EC19423; Tue, 31 Mar 2026 09:40:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774950030; bh=T7KhY3GM2hmdjQuBjDcNWz4pOtoqYT5vZ5McUEpAqqo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=r7HQNcqpn9km9vbR1ewA1TCeXTJqJ5YhOKdfSl9Xrq34yEDVSVx+YTxeNK/Uyky8y 5TbMzyRZnb66iek3LES1wnqZCxRa3vutvlcqBIWxKxNe91zwBSr8+or/0D0tgy2BuR 5c9JdJQ9FHa8KeVMJ0wgNyxlbppZZMf070A6pUMyKC4AhK3ZiPOHZp7fw7fiPkxSkw VywV6PEX6tBJ7TcIbsmqToD+pFI+gDx/hUWI0EbDheZjRgL4bMe+v5b5MJnVPb0MZE AZYYCvF9/AnnBilB1VhytX/2vXFxUKeA12EFKbebFGoWnTCS9U/7Xv5VLx+1Yfkipw Uv4CFZG4cqwLQ== From: Pratyush Yadav To: Pasha Tatashin Cc: rppt@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, dmatlack@google.com, pratyush@kernel.org, skhawaja@google.com Subject: Re: [PATCH v3 01/10] liveupdate: Safely print untrusted strings In-Reply-To: (Pasha Tatashin's message of "Fri, 27 Mar 2026 09:16:19 -0400") References: <20260327033335.696621-1-pasha.tatashin@soleen.com> <20260327033335.696621-2-pasha.tatashin@soleen.com> Date: Tue, 31 Mar 2026 09:40:26 +0000 Message-ID: <2vxzmrzoibg5.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Pasha, On Fri, Mar 27 2026, Pasha Tatashin wrote: > On Thu, Mar 26, 2026 at 11:33=E2=80=AFPM Pasha Tatashin > wrote: >> >> Deserialized strings from KHO data (such as file handler compatible >> strings and session names) are provided by the previous kernel and >> might not be null-terminated if the data is corrupted or maliciously >> crafted. >> >> When printing these strings in error messages, use the %.*s format >> specifier with the maximum buffer size to prevent out-of-bounds reads >> into adjacent kernel memory. >> >> Signed-off-by: Pasha Tatashin >> --- >> kernel/liveupdate/luo_file.c | 3 ++- >> kernel/liveupdate/luo_session.c | 3 ++- >> 2 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c >> index 5acee4174bf0..a6d98fc75d25 100644 >> --- a/kernel/liveupdate/luo_file.c >> +++ b/kernel/liveupdate/luo_file.c >> @@ -785,7 +785,8 @@ int luo_file_deserialize(struct luo_file_set *file_s= et, >> } >> >> if (!handler_found) { >> - pr_warn("No registered handler for compatible '%= s'\n", >> + pr_warn("No registered handler for compatible '%= .*s'\n", >> + (int)sizeof(file_ser[i].compatible), >> file_ser[i].compatible); >> return -ENOENT; >> } >> diff --git a/kernel/liveupdate/luo_session.c b/kernel/liveupdate/luo_ses= sion.c >> index 25ae704d7787..8c76dece679b 100644 >> --- a/kernel/liveupdate/luo_session.c >> +++ b/kernel/liveupdate/luo_session.c >> @@ -544,7 +544,8 @@ int luo_session_deserialize(void) >> >> session =3D luo_session_alloc(sh->ser[i].name); >> if (IS_ERR(session)) { >> - pr_warn("Failed to allocate session [%s] during = deserialization %pe\n", >> + pr_warn("Failed to allocate session [%.*s] durin= g deserialization %pe\n", >> + (int)sizeof(sh->ser[i].name), >> sh->ser[i].name, session); >> return PTR_ERR(session); >> } > > Lol, Sashiko went a little overboard and gave this patch two > "Critical" findings: > > 1. If a registered file handler uses a compatible string equal to or long= er than > the buffer, and the untrusted string matches it without a null terminator, > strcmp() could read past the bounds of file_ser[i].compatible. > > B.S.: The length of the string is ABI, and fh->compatible is a > NULL-terminated string provided by the current kernel. In the future, > we can replace strcmp() with strncmp(), but it is not a high-priority > issue. > > 2. By returning PTR_ERR(session) directly without updating the static err > variable, subsequent calls will see is_deserialized as true and return 0. > > This is regarding luo_session_deserialize(), that is the intended > behavior. We attempt deserialization exactly once, and if it fails, > some resources stay "leaked" and inaccessible to the user until the > next reboot. This is the safest approach to avoid data leaks. I think you misunderstood. Sashiko brings up a very good point. The problem is not that we don't attempt the deserialization again, the problem is that this code path doesn't set err. So this results in is_deserialized =3D=3D true, but err =3D=3D 0 even though deserialization failed. So the next attempt to open /dev/liveupdate will succeed since if (is_deserialized) return err; will return 0. So I think you need to do: err =3D PTR_ERR(session); return err; To make sure this error code gets recorded and the next open of /dev/liveupdate also fails. Anyway, this isn't directly related to this patch but it is a real bug that should be fixed in a separate patch. --=20 Regards, Pratyush Yadav