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-next>] [day] [month] [year] [list]
Message-ID: <YxhKp4n7K4h3aMQt@work>
Date:   Wed, 7 Sep 2022 08:39:19 +0100
From:   "Gustavo A. R. Silva" <gustavoars@...nel.org>
To:     kernel test robot <oliver.sang@...el.com>
Cc:     Kees Cook <keescook@...omium.org>, lkp@...ts.01.org, lkp@...el.com,
        linux-hardening@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Shuah Khan <shuah@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Tom Rix <trix@...hat.com>, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [fortify]  728833277d:
 WARNING:at_net/netlink/af_netlink.c:#netlink_ack

On Wed, Sep 07, 2022 at 01:42:16PM +0800, kernel test robot wrote:

Hi!

> 
> Hi Kees Cook,
> 
> the patch "[PATCH 1/2] fortify: Add run-time WARN for cross-field memcpy()"
> raises a persistent WARNING as below report in our tests.
> 
> according to commit message, we understand this is kind of expected. but
> we don't have enough knowledge if it reveals a real issue in kernel source
> code and what the next step could be.
> 
> so we still report FYI.
> 
> if you think it's unnecessary for us to make out this kind of report, please
> let us know. we will consider how to refine our report rules. Thanks a lot!
> 
> below is the full report.

It seems that the idea is to continue reporting these warnings, as they
help us identify the places that need to be audited and determine how to
refactor the code (in case it's a false positive), or how to properly fix
it (in case it's an actual bug).

In this case, it seems that the issue was already addressed by this patch:

https://lore.kernel.org/linux-hardening/20220903043749.3102675-1-keescook@chromium.org/

Thanks
--
Gustavo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ