linux-kernel - Re: [GIT PULL] hwmon updates for v5.20

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-=wiGO=pfxyW6E7HdxCnRwWOF_STL=z7yUNwZK__DrV1WmQ@mail.gmail.com>
Date:   Sun, 7 Aug 2022 09:45:08 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>, Kees Cook <keescook@...omium.org>
Cc:     Guenter Roeck <linux@...ck-us.net>, linux-hwmon@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] hwmon updates for v5.20

Added Kees - this *looks* like it's a compiler bug.

On Sun, Aug 7, 2022 at 3:07 AM Ingo Molnar <mingo@...nel.org> wrote:
>
> Just a quick build regression report, i386 allmodconfig fails to build due
> to a 'string overread' compiler warning in drivers/hwmon/lm90.o:

I tried to see it here with gcc-12.1, but it's not triggering, so it's
presumably compiler-dependent.

Which compiler is it?

>       inlined from ‘lm90_detect’ at drivers/hwmon/lm90.c:2550:2:
> warning: ‘__builtin_strlen’ reading 1 or more bytes from a region of size 0 [-Wstringop-overread]

Normally it's easier to see what triggers it, but here it's just that

        strlcpy(info->type, name, I2C_NAME_SIZE);

so it's either just the compiler being confused (we've seen that
before), or it's one of the

                name = lm90_detect_xyz(client, chip_id, config1, convrate);

calls in the case statement above that returns something that gcc then
thinks is bad.

However, from an admittedly quick look, all those functions simply
seem to return either NULL or a simple constant string.

Which makes me think "oh, it's gcc being confused by the fortification
code again".

Kees? Do you see anything I don't?

I get the feeling that we should just disable
-Werror=stringop-overread and/or FORTIFY_SOURCE for that
compiler/architecture combination if it's just gcc causing bogus
errors.

              Linus