linux-hardening - Re: [TCWG CI] Regression caused by linux: Makefile: Enable -Warray-bounds

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:   Mon, 31 Jan 2022 23:52:19 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Arnd Bergmann <arnd@...aro.org>
Cc:     ci_notify@...aro.org,
        Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
        linux-hardening@...r.kernel.org
Subject: Re: [TCWG CI] Regression caused by linux: Makefile: Enable
 -Warray-bounds

On Tue, Feb 01, 2022 at 08:17:50AM +0100, Arnd Bergmann wrote:
> On Mon, Jan 31, 2022 at 11:30 PM Kees Cook <keescook@...omium.org> wrote:
> > On Sun, Jan 30, 2022 at 01:00:43AM +0000, ci_notify@...aro.org wrote:
> >
> > For example, extracting from the build log, I can see more:
> >
> > > 00:00:53 In file included from ./include/linux/io.h:13,
> > > 00:00:53                  from arch/arm/mach-cns3xxx/pm.c:8:
> > > 00:00:53 In function ‘__raw_readl’,
> > > 00:00:53     inlined from ‘cns3xxx_pwr_clk_en’ at arch/arm/mach-cns3xxx/pm.c:17:12:
> > > 00:00:53 ./arch/arm/include/asm/io.h:113:9: error: array subscript 0 is outside array bounds of ‘const volatile void[0]’ [-Werror=array-bounds]
> > > 00:00:53   113 |         asm volatile("ldr %0, %1"
> > > 00:00:53       |         ^~~
> >
> > Looks like something sees a "void" type... this smells like a compiler
> > bug. I haven't been able to reproduce this warning yet.
> 
> I suspect this is a variation of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> 
> When gcc sees a pointer dereference of a literal address like *(int
> *)(void *)0x1234000,
> this is sometimes interpreted as a NULL pointer with an offset, which
> in turn is
> assumed to have zero bytes that can be dereferenced.

Eww.

I still can't reproduce this error myself. Any hints on compiler
versions?

-- 
Kees Cook