[PATCH net 0/2] Netfilter fixes for net

[PATCH net 0/2] Netfilter fixes for net

[Pablo Neira Ayuso]

Hi,

The following patchset contains two Netfilter fixes for net:

1) Release bridge info once packet escapes the br_netfilter path,
   from Florian Westphal.

2) Revert incorrect fix for the SCTP connection tracking chunk
   iterator, also from Florian.

First path fixes a long standing issue, the second path addresses
a mistake in the previous pull request for net.

Please, pull these changes from:

  git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git

Thanks.

----------------------------------------------------------------

The following changes since commit 9b3fc325c2a7e9e17e22b008357cb0ceb810d9b2:

  Merge tag 'ieee802154-for-net-2023-01-30' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan (2023-01-30 21:11:11 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git HEAD

for you to fetch changes up to bd0e06f0def75ba26572a94e5350324474a55562:

  Revert "netfilter: conntrack: fix bug in for_each_sctp_chunk" (2023-01-31 14:02:48 +0100)

----------------------------------------------------------------
Florian Westphal (2):
      netfilter: br_netfilter: disable sabotage_in hook after first suppression
      Revert "netfilter: conntrack: fix bug in for_each_sctp_chunk"

 net/bridge/br_netfilter_hooks.c         | 1 +
 net/netfilter/nf_conntrack_proto_sctp.c | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

[PATCH net 1/2] netfilter: br_netfilter: disable sabotage_in hook after first suppression

[Pablo Neira Ayuso]

From: Florian Westphal <fw@strlen.de>

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@linogate.de>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/bridge/br_netfilter_hooks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index f20f4373ff40..9554abcfd5b4 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;
 	}
-- 
2.30.2

[PATCH net 2/2] Revert "netfilter: conntrack: fix bug in for_each_sctp_chunk"

[Pablo Neira Ayuso]

From: Florian Westphal <fw@strlen.de>

There is no bug.  If sch->length == 0, this would result in an infinite
loop, but first caller, do_basic_checks(), errors out in this case.

After this change, packets with bogus zero-length chunks are no longer
detected as invalid, so revert & add comment wrt. 0 length check.

Fixes: 98ee00774525 ("netfilter: conntrack: fix bug in for_each_sctp_chunk")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nf_conntrack_proto_sctp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
index 945dd40e7077..011d414038ea 100644
--- a/net/netfilter/nf_conntrack_proto_sctp.c
+++ b/net/netfilter/nf_conntrack_proto_sctp.c
@@ -142,10 +142,11 @@ static void sctp_print_conntrack(struct seq_file *s, struct nf_conn *ct)
 }
 #endif
 
+/* do_basic_checks ensures sch->length > 0, do not use before */
 #define for_each_sctp_chunk(skb, sch, _sch, offset, dataoff, count)	\
 for ((offset) = (dataoff) + sizeof(struct sctphdr), (count) = 0;	\
-	((sch) = skb_header_pointer((skb), (offset), sizeof(_sch), &(_sch))) &&	\
-	(sch)->length;	\
+	(offset) < (skb)->len &&					\
+	((sch) = skb_header_pointer((skb), (offset), sizeof(_sch), &(_sch)));	\
 	(offset) += (ntohs((sch)->length) + 3) & ~3, (count)++)
 
 /* Some validity checks to make sure the chunks are fine */
-- 
2.30.2

Re: [PATCH net 1/2] netfilter: br_netfilter: disable sabotage_in hook after first suppression

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (master)
by Pablo Neira Ayuso <pablo@netfilter.org>:

On Tue, 31 Jan 2023 14:31:57 +0100 you wrote:
> From: Florian Westphal <fw@strlen.de>
> 
> 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
> 
> [...]

Here is the summary with links:
  - [net,1/2] netfilter: br_netfilter: disable sabotage_in hook after first suppression
    https://git.kernel.org/netdev/net/c/2b272bb558f1
  - [net,2/2] Revert "netfilter: conntrack: fix bug in for_each_sctp_chunk"
    https://git.kernel.org/netdev/net/c/bd0e06f0def7

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html