linux-kernel - Re: Linux 6.19-rc1 mediatek mt7921e broke badly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6fc04df5-b753-4b2d-b978-0e59a7f48ff7@linux.dev>
Date: Mon, 29 Dec 2025 20:21:48 -0800
From: Matthew Schwartz <matthew.schwartz@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Thomas Weißschuh <linux@...ssschuh.net>,
 Eric Biggers <ebiggers@...nel.org>,
 Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>,
 Mario Limonciello <superm1@...nel.org>
Cc: Shuah Khan <skhan@...uxfoundation.org>, quan.zhou@...iatek.com,
 Felix Fietkau <nbd@....name>, lorenzo@...nel.org, ryder.lee@...iatek.com,
 linux-wireless@...r.kernel.org,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Linux ARM <linux-arm-kernel@...ts.infradead.org>,
 linux-mediatek@...ts.infradead.org, shuah <shuah@...nel.org>
Subject: Re: Linux 6.19-rc1 mediatek mt7921e broke badly

On 12/29/25 4:41 PM, Linus Torvalds wrote:
> On Sat, 27 Dec 2025 at 04:25, Thomas Weißschuh <linux@...ssschuh.net> wrote:
>>
>> Hi Shuah,
>>
>> On 2025-12-27 02:07:24-0700, Shuah Khan wrote:
>>> mt7921e doesn't load on my primary laptopn on Linux 6.19-rc1 and problem
>>> still there on 6.19-rc2.
>>
>> This should be a duplicate of
>> https://lore.kernel.org/all/CABXGCsMeAZyNJ-Axt_CUCXgyieWPV3rrcLpWsveMPT8R0YPGnQ@mail.gmail.com/
> 
> Hmm. I wonder if we could instead do this:
> 
>   --- a/lib/string.c
>   +++ b/lib/string.c
>   @@ -113,7 +113,7 @@ EXPORT_SYMBOL(strncpy);
>    ssize_t sized_strscpy(char *dest, const char *src, size_t count)
>    {
>           const struct word_at_a_time constants = WORD_AT_A_TIME_CONSTANTS;
>   -       size_t max = count;
>   +       size_t max = count - 1;
>           long res = 0;
> 
>           if (count == 0 || WARN_ON_ONCE(count > INT_MAX))
> 
> (intentionally whitespace-damaged patch, because I want people to
> think about it).

I gave this a try on its own but I was still experiencing a kernel crash:

[    3.339408] strnlen: detected buffer overflow: 17 byte read of buffer size 16
[    3.339804] WARNING: lib/string_helpers.c:1035 at __fortify_report+0x41/0x50, CPU#14: kworker/14:0/105
[    3.352248]  __fortify_panic+0xd/0xf
[    3.352259]  mt76_connac2_load_patch.cold+0x2b/0x95a [mt76_connac_lib 8f0d0f7b30f881af23462dac0a8cc5ff88d08cd0]

However, applying a similar diff in the fortify wrapper does prevent the crash:

--- a/include/linux/fortify-string.h
+++ b/include/linux/fortify-string.h
@@ -306,13 +306,13 @@ __FORTIFY_INLINE ssize_t sized_strscpy(char * const POS p, const char * const PO
      * This call protects from read overflow, because len will default to q
      * length if it smaller than size.
      */
-    len = strnlen(q, size);
+    len = strnlen(q, size - 1);
     /*
      * If len equals size, we will copy only size bytes which leads to
      * -E2BIG being returned.
      * Otherwise we will copy len + 1 because of the final '\O'.
      */
-    len = len == size ? size : len + 1;
+    len = len == size - 1 ? size : len + 1;
 
     /*
      * Generate a runtime write overflow error if len is greater than

Not sure what the implications of such a change would be relative to the proposed
fix here: https://lore.kernel.org/all/20251205161202.48409-1-mikhail.v.gavrilov@gmail.com/

Matt

> 
> It basically says that if the size of the 'strscpy()' buffer is N,
> then we do the "word-at-a-time" only up to 'N-1' bytes, because we
> don't even need to read the last byte of the source, because we will
> always NUL-terminate the destination...
> 
> That would basically make it ok to use a destination that is one byte
> larger than the source (in order to fit NUL termination that doesn't
> exist in the source).
> 
> The downside, of course, is that it means that we possibly miss out of
> doing the last word of the copy a word-at-a-time. But possibly not a
> big downside, and it would make strscpy() able to deal with this case
> natively.
> 
> The *real* issue is that we don't have a "source is this big,
> destination is that big" version of string copy.
> 
> Normally that is a non-issue - just pick the smaller size of the two.
> Except for this particular case, where the destination is exactly one
> byte larger, and wants to be NUL-terminated while the source might not
> be.
> 
> I haven't really thought this through fully, which is why that patch
> is very much whitespace-damaged. Somebody else should verify my
> thinking.
> 
>                    Linus
>