Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> On Mon, Jan 30, 2023 at 11:39:29AM +0100, Florian Westphal wrote:
> > When using a xfrm interface in a bridged setup (the outgoing device is
> > bridged), the incoming packets in the xfrm interface are only tracked
> > in the outgoing direction.
> >
> > $ brctl show
> > bridge name interfaces
> > br_eth1 eth1
> >
> > $ conntrack -L
> > tcp 115 SYN_SENT src=192... dst=192... [UNREPLIED] ...
> >
> > If br_netfilter is enabled, the first (encrypted) packet is received onR
> > eth1, conntrack hooks are called from br_netfilter emulation which
> > allocates nf_bridge info for this skb.
> >
> > If the packet is for local machine, skb gets passed up the ip stack.
> > The skb passes through ip prerouting a second time. br_netfilter
> > ip_sabotage_in supresses the re-invocation of the hooks.
> >
> > After this, skb gets decrypted in xfrm layer and appears in
> > network stack a second time (after decyption).
> >
> > Then, ip_sabotage_in is called again and suppresses netfilter
> > hook invocation, even though the bridge layer never called them
> > for the plaintext incarnation of the packet.
> >
> > Free the bridge info after the first suppression to avoid this.
>
> I'll add this tag (just one sufficiently old):
>
> Fixes: c4b0e771f906 ("netfilter: avoid using skb->nf_bridge directly")
>
> unless you prefer anything else.
I was unable to figure out where the regression comes from,
as far as i can see br_netfilter always had this problem; i did not
expect that skb is looped again with different headers.
I'm fine with a pseudo-tag.
