linux-kernel - Re: [PATCH] netfilter:get_next_corpse():No need to double check the *bucket

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191001093700.GD14819@breakpoint.cc>
Date:   Tue, 1 Oct 2019 11:37:00 +0200
From:   Florian Westphal <fw@...len.de>
To:     wh_bin@....com
Cc:     pablo@...filter.org, netfilter-devel@...r.kernel.org,
        coreteam@...filter.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] netfilter:get_next_corpse():No need to double check the
 *bucket

wh_bin@....com <wh_bin@....com> wrote:
> From: Hongbin Wang <wh_bin@....com>
> 
> The *bucket is in for loops,it has been checked.
> 
> Signed-off-by: Hongbin Wang <wh_bin@....com>
> ---
>  net/netfilter/nf_conntrack_core.c | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index 0c63120b2db2..8d48babe6561 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -2000,14 +2000,12 @@ get_next_corpse(int (*iter)(struct nf_conn *i, void *data),
>  		lockp = &nf_conntrack_locks[*bucket % CONNTRACK_LOCKS];
>  		local_bh_disable();
>  		nf_conntrack_lock(lockp);
> -		if (*bucket < nf_conntrack_htable_size) {
> -			hlist_nulls_for_each_entry(h, n, &nf_conntrack_hash[*bucket], hnnode) {
> -				if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL)
> -					continue;
> -				ct = nf_ct_tuplehash_to_ctrack(h);
> -				if (iter(ct, data))
> -					goto found;
> -			}
> +		hlist_nulls_for_each_entry(h, n, &nf_conntrack_hash[*bucket], hnnode) {

I don't think this is correct.
unless we hold nf_conntrack_lock() nf_conntrack_hash[] could be
reallocated, no?