Patch "netfilter: br_netfilter: disable sabotage_in hook after first suppression" has been added to the 5.15-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    netfilter: br_netfilter: disable sabotage_in hook after first suppression

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     netfilter-br_netfilter-disable-sabotage_in-hook-afte.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit b8c9bbc0d27f6af3fe366036c2321d94f5c5125c
Author: Florian Westphal <fw@xxxxxxxxx>
Date:   Mon Jan 30 11:39:29 2023 +0100

    netfilter: br_netfilter: disable sabotage_in hook after first suppression
    
    [ Upstream commit 2b272bb558f1d3a5aa95ed8a82253786fd1a48ba ]
    
    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 decryption).
    
    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 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.
    
    Fixes: c4b0e771f906 ("netfilter: avoid using skb->nf_bridge directly")
    Reported-and-tested-by: Wolfgang Nothdurft <wolfgang@xxxxxxxxxxx>
    Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
    Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index a718204c4bfd..f3c7cfba31e1 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -871,6 +871,7 @@ static unsigned int ip_sabotage_in(void *priv,
 	if (nf_bridge && !nf_bridge->in_prerouting &&
 	    !netif_is_l3_master(skb->dev) &&
 	    !netif_is_l3_slave(skb->dev)) {
+		nf_bridge_info_free(skb);
 		state->okfn(state->net, state->sk, skb);
 		return NF_STOLEN;
 	}