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: <CAHk-=wjO-7uR5HBi-MFnkxAxjhpgfbAQ+HCMKPiXFVwM+AJ7tA@mail.gmail.com>
Date: Mon, 29 Dec 2025 16:41:03 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: 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 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).

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