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

Date:   Tue, 1 Feb 2022 10:03:44 +0100
From:   Arnd Bergmann <arnd@...aro.org>
To:     Kees Cook <keescook@...omium.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 1, 2022 at 8:52 AM Kees Cook <keescook@...omium.org> wrote:
> 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?

The godbolt.org link in my report shows this as reproducible with any
gcc-11.x version but not gcc-10 or earlier.

       Arnd