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: <c84557e6-aa92-42e9-8768-e246676ec1e9@kernel.org>
Date: Sat, 3 Jan 2026 12:10:45 +0100
From: Vincent Mailhol <mailhol@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>,
 Randy Dunlap <rdunlap@...radead.org>
Cc: 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 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?

>  		return true;
>  	return false;
>  }

Yours sincerely,
Vincent Mailhol