From: Pratyush Yadav <pratyush@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
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
Date: Tue, 31 Mar 2026 09:40:26 +0000 [thread overview]
Message-ID: <2vxzmrzoibg5.fsf@kernel.org> (raw)
In-Reply-To: <CA+CK2bDJJ2exSz4i3by3QLX1xvLAyqG5L+UipraiQw3Ytmx2=w@mail.gmail.com> (Pasha Tatashin's message of "Fri, 27 Mar 2026 09:16:19 -0400")
Hi Pasha,
On Fri, Mar 27 2026, Pasha Tatashin wrote:
> On Thu, Mar 26, 2026 at 11:33 PM Pasha Tatashin
> <pasha.tatashin@soleen.com> 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 <pasha.tatashin@soleen.com>
>> ---
>> 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_set,
>> }
>>
>> 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_session.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 = 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] during 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 longer 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 == true, but err == 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 = 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.
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-03-31 9:40 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 3:33 [PATCH v3 00/10] liveupdate: Fix module unloading and unregister API Pasha Tatashin
2026-03-27 3:33 ` [PATCH v3 01/10] liveupdate: Safely print untrusted strings Pasha Tatashin
2026-03-27 13:16 ` Pasha Tatashin
2026-03-31 9:40 ` Pratyush Yadav [this message]
2026-03-31 9:50 ` Pratyush Yadav
2026-03-31 16:35 ` Pasha Tatashin
2026-03-27 3:33 ` [PATCH v3 02/10] liveupdate: Synchronize lazy initialization of FLB private state Pasha Tatashin
2026-03-31 10:38 ` Pratyush Yadav
2026-03-31 16:41 ` Pasha Tatashin
2026-03-31 19:22 ` Pratyush Yadav
2026-03-31 19:38 ` Pasha Tatashin
2026-03-27 3:33 ` [PATCH v3 03/10] liveupdate: Protect file handler list with rwsem Pasha Tatashin
2026-03-30 16:48 ` Samiullah Khawaja
2026-03-30 19:32 ` Pasha Tatashin
2026-03-31 19:24 ` Pratyush Yadav
2026-03-27 3:33 ` [PATCH v3 04/10] liveupdate: Protect FLB lists with luo_register_rwlock Pasha Tatashin
2026-03-31 19:33 ` Pratyush Yadav
2026-03-27 3:33 ` [PATCH v3 05/10] liveupdate: Defer FLB module refcounting to active sessions Pasha Tatashin
2026-03-30 16:56 ` Samiullah Khawaja
2026-03-30 19:28 ` Pasha Tatashin
2026-04-02 16:21 ` Pratyush Yadav
2026-03-27 3:33 ` [PATCH v3 06/10] liveupdate: Remove luo_session_quiesce() Pasha Tatashin
2026-04-02 16:27 ` Pratyush Yadav
2026-03-27 3:33 ` [PATCH v3 07/10] liveupdate: Auto unregister FLBs on file handler unregistration Pasha Tatashin
2026-04-03 10:17 ` Pratyush Yadav
2026-03-27 3:33 ` [PATCH v3 08/10] liveupdate: Remove liveupdate_test_unregister() Pasha Tatashin
2026-04-03 10:20 ` Pratyush Yadav
2026-03-27 3:33 ` [PATCH v3 09/10] liveupdate: Make unregister functions return void Pasha Tatashin
2026-03-27 14:41 ` Pasha Tatashin
2026-04-03 10:41 ` Pratyush Yadav
2026-03-27 3:33 ` [PATCH v3 10/10] liveupdate: Defer file handler module refcounting to active sessions Pasha Tatashin
2026-03-27 17:14 ` Andrew Morton
2026-04-03 10:42 ` Pratyush Yadav
2026-03-27 17:24 ` [PATCH v3 00/10] liveupdate: Fix module unloading and unregister API Andrew Morton
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=2vxzmrzoibg5.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dmatlack@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
/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