linux-kernel - Re: [PATCH] bpf: fix netfilter link comparison to handle unsigned flags

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] [day] [month] [year] [list]

Message-ID: <72f0108c-ce6c-4f89-b04d-2398d7c808a5@kernel.org>
Date: Sat, 20 Sep 2025 01:22:11 +0100
From: Quentin Monnet <qmo@...nel.org>
To: Haofeng Li <920484857@...com>, Alexei Starovoitov <ast@...nel.org>
Cc: Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, linux-kernel@...r.kernel.org,
 Haofeng Li <13266079573@....com>, lihaofeng <lihaofeng@...inos.cn>
Subject: Re: [PATCH] bpf: fix netfilter link comparison to handle unsigned
 flags

2025-09-19 17:04 UTC+0800 ~ Haofeng Li <920484857@...com>
> From: lihaofeng <lihaofeng@...inos.cn>
> 
> The original implementation of netfilter_link_compar() used subtraction
> to compare the netfilter.flags field, which is  an unsigned type.
> This could result in incorrect comparison results when the unsigned
> value wrapped around due to underflow.
> 
> Changed the comparison logic for flags to use explicit conditional
> checks (similar to how priority is handled) instead of subtraction,
> ensuring correct negative/zero/positive return values regardless of
> the underlying data type.
> 
> This fixes potential sorting issues when using this comparison function
> with algorithms like qsort() or bsearch().
> 
> Signed-off-by: lihaofeng <lihaofeng@...inos.cn>
> ---
>  tools/bpf/bpftool/net.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
> index cfc6f944f7c3..9f840821beda 100644
> --- a/tools/bpf/bpftool/net.c
> +++ b/tools/bpf/bpftool/net.c
> @@ -816,7 +816,11 @@ static int netfilter_link_compar(const void *a, const void *b)
>  	if (nfa->netfilter.priority > nfb->netfilter.priority)
>  		return 1;
>  
> -	return nfa->netfilter.flags - nfb->netfilter.flags;
> +	if (nfa->netfilter.flags < nfb->netfilter.flags)
> +		return -1;
> +	if (nfa->netfilter.flags > nfb->netfilter.flags)
> +		return 1;
> +	return 0;
>  }
>  

Thanks! Did you actually observe an overflow producing an error when
sorting, here? Or did you run into some compiler warning? If I'm not
mistaken you'd need the difference between flags for nfa and nfb to be
bigger than 1 << 31 for the sign to reverse. As far as I can tell, the
netfilter.flags can be 0 or 1, so this is unlikely to happen. I note
that fields netfilter.pf and netfilter.hooknum are processed in a
similar way earlier in the function, with the types allowing overflows
but possible values preventing the comparison to reverse in practice.

This being said, I don't mind making the code cleaner for these
comparisons, but we should probably treat all three attributes the same,
and update the rest of the function as well?

Quentin