linux-hardening - Re: [PATCH] overflow: Update is_non_negative() and is

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: <e66bd09b-9879-4562-a71e-a1e1a964f3f2@kernel.org>
Date: Sat, 3 Jan 2026 20:40:17 +0100
From: Vincent Mailhol <mailhol@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Randy Dunlap <rdunlap@...radead.org>,
 Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
 Nicolas Schier <nicolas@...sle.eu>, Nathan Chancellor <nathan@...nel.org>,
 Nicolas Schier <nsc@...nel.org>,
 Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
 Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Chris Mason <clm@...com>, David Sterba <dsterba@...e.com>,
 Kees Cook <kees@...nel.org>, "Gustavo A. R. Silva" <gustavoars@...nel.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 linux-kbuild@...r.kernel.org, linux-sparse@...r.kernel.org,
 linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
 dri-devel@...ts.freedesktop.org, linux-btrfs@...r.kernel.org,
 linux-hardening@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] overflow: Update is_non_negative() and is_negative()
 comment

On 03/01/2026 at 17:56, Dan Carpenter wrote:
> On Sat, Jan 03, 2026 at 12:10:45PM +0100, Vincent Mailhol wrote:
>> On 03/01/2026 at 11:02, Dan Carpenter wrote:
>>> Thanks Randy, for sending this to me.  I'm on the sparse list, but
>>> I've been on vacation and haven't caught up with my email. 
>>
>> Welcome back, hope you enjoyed your holidays!
>>
>>> I can easily silence this in Smatch.
>>
>> Thanks. I ran this locally, I can confirm that this silences the
>> warning. So:
>>
>> Tested-by: Vincent Mailhol <mailhol@...nel.org>
>>
>>> diff --git a/check_unsigned_lt_zero.c b/check_unsigned_lt_zero.c
>>> index bfeb3261f91d..ac3e650704ce 100644
>>> --- a/check_unsigned_lt_zero.c
>>> +++ b/check_unsigned_lt_zero.c
>>> @@ -105,7 +105,8 @@ static bool is_allowed_zero(struct expression *expr)
>>>  	    strcmp(macro, "STRTO_H") == 0 ||
>>>  	    strcmp(macro, "SUB_EXTEND_USTAT") == 0 ||
>>>  	    strcmp(macro, "TEST_CASTABLE_TO_TYPE_VAR") == 0 ||
>>> -	    strcmp(macro, "TEST_ONE_SHIFT") == 0)
>>> +	    strcmp(macro, "TEST_ONE_SHIFT") == 0 ||
>>> +	    strcmp(macro, "check_shl_overflow") == 0)
>>
>> But, for the long term, wouldn't it better to just ignore all the code
>> coming from macro extensions instead of maintaining this allow-list?
>>
> 
> Of course, that idea occured to me, but so far the allow list is not
> very burdensome to maintain.

Indeed, but my concern was more on how people would treat such smatch
warnings coming from the kernel test robot. It is very uncommon to have
an allow-list hard coded into the static analyzer. Actually, this is the
first time I see this. My fear here is that people will just uglify the
code rather than sending a patch to extend the allow list in smatch.

> I maybe should disable it for all macros unless the --spammy option is used...

IMHO, that would be an even better approach. That said, I am happy
enough with your previous patch which resolves my issue and which is way
better than updating the is_non_negative() and is_negative() comments as
I did in my patch!

Yours sincerely,
Vincent Mailhol