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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ