netdev - Re: [PATCH v16 nf-next 3/3] netfilter: nft_chain_filter: Add bridge double vlan and pppoe

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: <aQ0zja96khMMZfsq@strlen.de>
Date: Fri, 7 Nov 2025 00:47:25 +0100
From: Florian Westphal <fw@...len.de>
To: Eric Woudstra <ericwouds@...il.com>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
	Jozsef Kadlecsik <kadlec@...filter.org>, Phil Sutter <phil@....cc>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	Ido Schimmel <idosch@...dia.com>,
	"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,
	bridge@...ts.linux.dev, netdev@...r.kernel.org
Subject: Re: [PATCH v16 nf-next 3/3] netfilter: nft_chain_filter: Add bridge
 double vlan and pppoe

Eric Woudstra <ericwouds@...il.com> wrote:
> >> +		return NF_ACCEPT;
> > 
> > 
> > Hmm.  I'm not sure, I think this should either drop them right away
> > OR pass them to do_chain without any changes (i.e. retain existing
> > behavior and have this be same as nft_set_pktinfo_unspec()).
> > 
> > but please wait until resend.
> > 
> > I hope to finish a larger set i've been working on by tomorrow.
> > Then I can give this a more thorough review (and also make a summary +
> > suggestion wrt. the bridge match semantics wrt.  vlan + pppoe etc.
> > 
> > My hunch is that your approach is pretty much the way to go
> > but I need to complete related homework to make sure I did not
> > miss/forget anything.
> 
> I understand. I've send this, because from v5 to v15 it moved towards
> matching in the rule, but it all started with the fact that
> nft_flow_offload_eval() uses nft_thoff().
> 
> At a bare minimum I need to address having pkt->thoff set correctly to
> implement the software bridge-fastpath.

Sorry, fail to see how thats related.

If the header is incomplete, then with your approach the packet isn't
even seen by nft_flow_offload_eval() (-> NF_ACCEPT'd).

Whats the problem with passing the skb to nft_do_chain in its
'original' form?