linux-kernel - Re: [PATCH 4/5] 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:   Wed, 2 Feb 2022 15:33:11 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
        Masahiro Yamada <masahiroy@...nel.org>,
        linux-kbuild@...r.kernel.org,
        "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        clang-built-linux@...glegroups.com, linux-hardening@...r.kernel.org
Subject: Re: [PATCH 4/5] Makefile: Enable -Warray-bounds

On 2/2/22 12:56, Kees Cook wrote:
> On Wed, Feb 02, 2022 at 08:09:03AM -0800, Guenter Roeck wrote:
>> On Wed, Aug 18, 2021 at 01:11:17AM -0700, Kees Cook wrote:
>>> With the recent fixes for flexible arrays and expanded FORTIFY_SOURCE
>>> coverage, it is now possible to enable -Warray-bounds. Since both
>>> GCC and Clang include -Warray-bounds in -Wall, we just need to stop
>>> disabling it.
>>>
>>> Cc: Arnd Bergmann <arnd@...db.de>
>>> Cc: Masahiro Yamada <masahiroy@...nel.org>
>>> Cc: linux-kbuild@...r.kernel.org
>>> Co-developed-by: Gustavo A. R. Silva <gustavoars@...nel.org>
>>> Signed-off-by: Gustavo A. R. Silva <gustavoars@...nel.org>
>>> Signed-off-by: Kees Cook <keescook@...omium.org>
>>> ---
>>>   Makefile | 1 -
>>>   1 file changed, 1 deletion(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index a4aca01a4835..af22b83cede7 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1072,7 +1072,6 @@ KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
>>>   
>>>   # We'll want to enable this eventually, but it's not going away for 5.7 at least
>>>   KBUILD_CFLAGS += $(call cc-disable-warning, zero-length-bounds)
>>> -KBUILD_CFLAGS += -Wno-array-bounds
>>>   KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow)
>>>   
>>>   # Another good warning that we'll want to enable eventually
>>
>> alpha:defconfig:
>>
>> In function '__memset',
>>      inlined from '__bad_pagetable' at arch/alpha/mm/init.c:79:2:
>> ./arch/alpha/include/asm/string.h:37:32: error: '__builtin_memset' offset [0, 8191] is out of the bounds [0, 0] [-Werror=array-bounds]
>>     37 |                         return __builtin_memset(s, c, n);
>>        |                                ^~~~~~~~~~~~~~~~~~~~~~~~~
>> In function '__memset',
>>      inlined from '__bad_page' at arch/alpha/mm/init.c:86:2:
>> ./arch/alpha/include/asm/string.h:37:32: error: '__builtin_memset' offset [0, 8191] is out of the bounds [0, 0] [-Werror=array-bounds]
>>     37 |                         return __builtin_memset(s, c, n);
>>        |                                ^~~~~~~~~~~~~~~~~~~~~~~~~
>> In function '__memset',
>>      inlined from 'paging_init' at arch/alpha/mm/init.c:256:2:
>> ./arch/alpha/include/asm/string.h:37:32: error: '__builtin_memset' offset [0, 8191] is out of the bounds [0, 0] [-Werror=array-bounds]
>>     37 |                         return __builtin_memset(s, c, n);
> 
> Thanks! I'll take a look. Every instance of the "[0, 0]" bounds means
> the compiler believes there's a way for the destination to be determined
> at compile-time to be NULL.
> 
>> xtensa:allmodconfig:
>> --------------
>> Error log:
>> In file included from include/linux/uaccess.h:11,
>>                   from include/linux/sched/task.h:11,
>>                   from arch/xtensa/kernel/process.c:21:
>> arch/xtensa/kernel/process.c: In function 'copy_thread':
>> arch/xtensa/kernel/process.c:262:52: error: array subscript 53 is above array bounds of 'long unsigned int[16]'
> 
> I assume this is a weird cast. I will also check this one out.
> 

                                 int callinc = (regs->areg[0] >> 30) & 3;
                                 int caller_ars = XCHAL_NUM_AREGS - callinc * 4;
                                 put_user(regs->areg[caller_ars+1],
                                          ^^^^^^^^^^^^^^^^^^^^^^^^
                                          (unsigned __user*)(usp - 12));

I think the problem is that XCHAL_NUM_AREGS can be up to 64,
but the size of struct pt_regs->areg[] is fixed to 16.

Guenter