linux-kernel - Re: [alobakin:pfcp 11/19] include/linux/bitmap.h:642:17: warning: array subscript [1, 1024] is outside array bounds of 'long unsigned int[1]'

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: <CAG_fn=WPNROrC4ndAa_JOoOiWYSh3gQat1fqiv+3jdvFXcpw=A@mail.gmail.com>
Date:   Wed, 8 Nov 2023 11:07:44 +0100
From:   Alexander Potapenko <glider@...gle.com>
To:     Yury Norov <yury.norov@...il.com>
Cc:     Alexander Lobakin <aleksander.lobakin@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Syed Nayyar Waris <syednwaris@...il.com>,
        Kees Cook <keescook@...omium.org>,
        kernel test robot <lkp@...el.com>,
        oe-kbuild-all@...ts.linux.dev, linux-hardening@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [alobakin:pfcp 11/19] include/linux/bitmap.h:642:17: warning:
 array subscript [1, 1024] is outside array bounds of 'long unsigned int[1]'

On Tue, Nov 7, 2023 at 8:24 PM Yury Norov <yury.norov@...il.com> wrote:
>
> On Tue, Nov 07, 2023 at 07:52:19PM +0100, Alexander Lobakin wrote:
> > From: Yury Norov <yury.norov@...il.com>
> > Date: Tue, 7 Nov 2023 10:32:06 -0800
> >
> > > On Tue, Nov 07, 2023 at 06:24:04PM +0100, Alexander Lobakin wrote:
> > >> From: Alexander Lobakin <aleksander.lobakin@...el.com>
> > >> Date: Tue, 7 Nov 2023 17:44:00 +0100
> > >>
> > >>> From: Alexander Potapenko <glider@...gle.com>
> > >>> Date: Tue, 7 Nov 2023 17:33:56 +0100
> > >>>
> > >>>> On Tue, Nov 7, 2023 at 2:23 PM Alexander Lobakin
> > >>>> <aleksander.lobakin@...el.com> wrote:
> > >>
> > >> [...]
> > >>
> > >>> I tested it on GCC 9 using modified make.cross from lkp and it triggers
> > >>> on one more file:
> > >>>
> > >>> drivers/thermal/intel/intel_soc_dts_iosf.c: In function 'sys_get_curr_temp':
> > >>> ./include/linux/bitmap.h:601:18: error: array subscript [1,
> > >>> 288230376151711744] is outside array bounds of 'long unsigned int[1]'
> > >>> [-Werror=array-bounds]
> > >>>
> > >>>> to give the compiler some hints about the range of values passed to
> > >>>> bitmap_write() rather than suppressing the optimizations.
> > >>>
> > >>> OPTIMIZER_HIDE_VAR() doesn't disable optimizations if I get it
> > >>> correctly, rather shuts up the compiler in cases like this one.
> > >>>
> > >>> I've been thinking of using __member_size() from fortify-string.h, we
> > >>> could probably optimize the object code even a bit more while silencing
> > >>> this warning.
> > >>> Adding Kees, maybe he'd like to participate in sorting this out as well.
> > >>
> > >> This one seems to work. At least previously mad GCC 9.3.0 now sits
> > >> quietly, as if I added OPTIMIZER_HIDE_VAR() as Yury suggested.
> > >
> > > What's wrong with OPTIMIZER_HIDE_VAR()? The problem is clearly on GCC
> > > side, namely - it doesn't realize that the map[index+1] fetch is
> > > conditional.
> >
> > It's totally fine for me to use it, this one is just an alternative
> > (well, a bit broken as per below).
>
> OK, guys, that's even worse. The 12 and 13 don't fire the warning
> because Warray-bounds is explicitly disabled for gcc-11+. Check
> 0da6e5fd6c372 ("gcc: disable '-Warray-bounds' for gcc-13 too"). I'll
> test how gcc-10 builds it, and if it's broken too, it's worth to shift
> the threshold in init/Kconfig.

Yes, that's my point.
According to Godbolt, GCC versions 9.1 to 13.2 (trunk included) are
reporting the same false positive on the code I posted above.

In 5a41237ad1d4b62008f93163af1d9b1da90729d8 ("gcc: disable
-Warray-bounds for gcc-11 too") Linus says that "Older gcc versions
end up being increasingly less relevant", so I think there won't be
objections against extending this rule to GCC 9 and 10.