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: 36+ 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-04-13 16:43 ` Pasha Tatashin
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-04-13 18:06 ` Pasha Tatashin
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 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.