linux-kernel - Re: Soft lock-ups caused by iptables

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: <aR76EHWHhsfGoiMi@orbyte.nwl.cc>
Date: Thu, 20 Nov 2025 12:22:56 +0100
From: Phil Sutter <phil@....cc>
To: Florian Westphal <fw@...len.de>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
	Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>,
	netdev@...r.kernel.org, Jozsef Kadlecsik <kadlec@...filter.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, netfilter-devel@...r.kernel.org,
	coreteam@...filter.org, linux-kernel@...r.kernel.org
Subject: Re: Soft lock-ups caused by iptables

On Thu, Nov 20, 2025 at 10:34:46AM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@...filter.org> wrote:
> > > > Yes, but you also need to annotate the type of the last base chain origin,
> > > > else you might skip validation of 'chain foo' because its depth value says its
> > > > fine but new caller is coming from filter, not nat, and chain foo had
> > > > masquerade expression.
> > 
> > You could also have chains being called from different levels.
> 
> But thats not an issue.  If you see a jump from c1 to c2, and c2
> has been validated for a level of 5, then you need to revalidate
> only if c1->depth >= 5.
> 
> Do you see any issue with this? (it still lacks annotation for
> the calling basechains type, so this cannot be applied as-is):

Assuming that we don't allow jumps from one family to another, we may
get by with two bitfields which validate callbacks fill: One for base
chain types and one for hooks.

The current family would still be validated inside the callback, but
nft_chain_validate_dependency() and nft_chain_validate_hooks() called
once (I think) for each base chain after collecting. The callbacks could
also return void and leave the hooks bitmask zeroed to signal "invalid
family".

> netfilter: nf_tables: avoid chain re-validation if possible

Thanks, Phil