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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c1304430-dd7d-437b-8744-70af9ca85c0d@linuxfoundation.org>
Date: Tue, 30 Dec 2025 16:57:20 -0700
From: Shuah Khan <skhan@...uxfoundation.org>
To: Matthew Schwartz <matthew.schwartz@...ux.dev>,
 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>,
 Johannes Berg <johannes@...solutions.net>
Cc: 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>,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: Linux 6.19-rc1 mediatek mt7921e broke badly

On 12/29/25 21:21, Matthew Schwartz wrote:
> 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/

+ adding Johannes to this thread also.

Reverting the following fixed my problem.
  
f804a5895eba ("wifi: mt76: Strip whitespace from build ddate")

The above fixes an extra newline in the dmesg by making the
code more complex it needs to introducing local buffers and
strscpy() - the proposed fix replaces this with memcpy().

Is there a simple way to do this than introducing memcpy()
or strscpy() to remove an extra newline that might or might
not exist? Why not check if newline exists or not using
strstr()?

I would recommend reverting f804a5895eba instead of trying
fix it. Then find a better way to eliminate extra newline that
shows up in dmesg when firmware build date happens to have
a newline.

thanks,
-- Shuah