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: <aT22cheoCSd1JfIM@strlen.de>
Date: Sat, 13 Dec 2025 19:54:42 +0100
From: Florian Westphal <fw@...len.de>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
	syzbot <syzbot+4393c47753b7808dac7d@...kaller.appspotmail.com>,
	coreteam@...filter.org, davem@...emloft.net, horms@...nel.org,
	kadlec@...filter.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
	pabeni@...hat.com, pablo@...filter.org, phil@....cc,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [netfilter?] WARNING in nf_conntrack_cleanup_net_list

Eric Dumazet <edumazet@...gle.com> wrote:
> > UDP, but I can't say yet if thats an udp specific issue or not.
> > (the packets are generated via ip_defrag.c).
> 
> skb_release_head_state() does not follow the fraglist. Oh well.
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index a00808f7be6a1b86c595183f8b131996e3d0afcc..f597769d8c206dc063b53938a18edbe9620101d9
> 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -1497,7 +1497,9 @@ void napi_consume_skb(struct sk_buff *skb, int budget)
> 
>         DEBUG_NET_WARN_ON_ONCE(!in_softirq());
> 
> -       if (skb->alloc_cpu != smp_processor_id() && !skb_shared(skb)) {
> +       if (skb->alloc_cpu != smp_processor_id() &&
> +           !skb_shared(skb) &&
> +           !skb_has_frag_list(skb)) {
>                 skb_release_head_state(skb);
>                 return skb_attempt_defer_free(skb);

There is also:
skb_attempt_defer_free -> skb_attempt_defer_free

Alternatively we could export skb_defer_free_flush or
kick_defer_list_purge() and call that from nf_conntrack
net exit path.

I will investigate more closely on monday, I still don't
understand why fragments are conntracked in the first place.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ