[PATCH net-next 0/9] Netfilter updates for net-next

[PATCH net-next 0/9] Netfilter updates for net-next

[Florian Westphal]

Hello,

following patch set includes netfilter updates for your *net-next* tree.

1. Replace pr_debug use with nf_log infra for debugging in sctp
   conntrack.
2. Remove pr_debug calls, they are either useless or we have better
   options in place.
3. Avoid repeated load of ct->status in some spots.
   Some bit-flags cannot change during the lifeetime of
   a connection, so no need to re-fetch those.
4. Avoid uneeded nesting of rcu_read_lock during tuple lookup.
5. Remove the CLUSTERIP target.  Marked as obsolete for years,
   and we still have WARN splats wrt. races of the out-of-band
   /proc interface installed by this target.
6. Add static key to nf_tables to avoid the retpoline mitigation
   if/else if cascade provided the cpu doesn't need the retpoline thunk.
7. add nf_tables objref calls to the retpoline mitigation workaround.
8. Split parts of nft_ct.c that do not need symbols exported by
   the conntrack modules and place them in nf_tables directly.
   This allows to avoid indirect call for 'ct status' checks.
9. Add 'destroy' commands to nf_tables.  They are identical
   to the existing 'delete' commands, but do not indicate
   an error if the referenced object (set, chain, rule...)
   did not exist, from Fernando.

The following changes since commit c4791b3196bf46367bcf6cc56a09b32e037c4f49:

  Merge branch 'net-mdio-continue-separating-c22-and-c45' (2023-01-17 19:34:10 -0800)

are available in the Git repository at:

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

for you to fetch changes up to f80a612dd77c4585171e44a06b490466bdeec1ae:

  netfilter: nf_tables: add support to destroy operation (2023-01-18 13:09:00 +0100)

----------------------------------------------------------------
Fernando Fernandez Mancera (1):
      netfilter: nf_tables: add support to destroy operation

Florian Westphal (8):
      netfilter: conntrack: sctp: use nf log infrastructure for invalid packets
      netfilter: conntrack: remove pr_debug calls
      netfilter: conntrack: avoid reload of ct->status
      netfilter: conntrack: move rcu read lock to nf_conntrack_find_get
      netfilter: ip_tables: remove clusterip target
      netfilter: nf_tables: add static key to skip retpoline workarounds
      netfilter: nf_tables: avoid retpoline overhead for objref calls
      netfilter: nf_tables: avoid retpoline overhead for some ct expression calls

 include/net/netfilter/nf_tables_core.h   |  16 +
 include/uapi/linux/netfilter/nf_tables.h |  14 +
 net/ipv4/netfilter/Kconfig               |  14 -
 net/ipv4/netfilter/Makefile              |   1 -
 net/ipv4/netfilter/ipt_CLUSTERIP.c       | 929 -------------------------------
 net/netfilter/Makefile                   |   6 +
 net/netfilter/nf_conntrack_core.c        |  46 +-
 net/netfilter/nf_conntrack_proto.c       |  20 +-
 net/netfilter/nf_conntrack_proto_sctp.c  |  46 +-
 net/netfilter/nf_conntrack_proto_tcp.c   |   9 -
 net/netfilter/nf_conntrack_proto_udp.c   |  10 +-
 net/netfilter/nf_tables_api.c            | 111 +++-
 net/netfilter/nf_tables_core.c           |  35 +-
 net/netfilter/nft_ct.c                   |  39 +-
 net/netfilter/nft_ct_fast.c              |  56 ++
 net/netfilter/nft_objref.c               |  12 +-
 16 files changed, 302 insertions(+), 1062 deletions(-)
 delete mode 100644 net/ipv4/netfilter/ipt_CLUSTERIP.c
 create mode 100644 net/netfilter/nft_ct_fast.c
-- 
2.38.2

[PATCH net-next 0/9] Netfilter updates for net-next

[Florian Westphal]

Hi,

The following set contains updates for the *net-next* tree:

1. nf_tables 'brouting' support, from Sriram Yagnaraman.

2. Update bridge netfilter and ovs conntrack helpers to handle
   IPv6 Jumbo packets properly, i.e. fetch the packet length
   from hop-by-hop extension header, from Xin Long.

   This comes with a test BIG TCP test case, added to
   tools/testing/selftests/net/.

3. Fix spelling and indentation in conntrack, from Jeremy Sowden.

Please consider pulling from

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

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

The following changes since commit 7d8c48917a9576b5fc8871aa4946149b0e4a4927:

  dt-bindings: net: dsa: mediatek,mt7530: change some descriptions to literal (2023-03-08 13:05:37 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git main

for you to fetch changes up to b0ca200077b3872056e6a8291c9a50f803658c2a:

  netfilter: nat: fix indentation of function arguments (2023-03-08 14:25:44 +0100)

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

Jeremy Sowden (2):
  netfilter: conntrack: fix typo
  netfilter: nat: fix indentation of function arguments

Sriram Yagnaraman (1):
  netfilter: bridge: introduce broute meta statement

Xin Long (6):
  netfilter: bridge: call pskb_may_pull in br_nf_check_hbh_len
  netfilter: bridge: check len before accessing more nh data
  netfilter: bridge: move pskb_trim_rcsum out of br_nf_check_hbh_len
  netfilter: move br_nf_check_hbh_len to utils
  netfilter: use nf_ip6_check_hbh_len in nf_ct_skb_network_trim
  selftests: add a selftest for big tcp

 include/linux/netfilter_ipv6.h           |   2 +
 include/uapi/linux/netfilter/nf_tables.h |   2 +
 net/bridge/br_netfilter_ipv6.c           |  79 ++--------
 net/bridge/netfilter/nft_meta_bridge.c   |  71 ++++++++-
 net/netfilter/nf_conntrack_core.c        |   2 +-
 net/netfilter/nf_conntrack_ovs.c         |  11 +-
 net/netfilter/nf_nat_core.c              |   4 +-
 net/netfilter/utils.c                    |  52 +++++++
 tools/testing/selftests/net/Makefile     |   1 +
 tools/testing/selftests/net/big_tcp.sh   | 180 +++++++++++++++++++++++
 10 files changed, 327 insertions(+), 77 deletions(-)
 create mode 100755 tools/testing/selftests/net/big_tcp.sh

[PATCH net-next 0/9] Netfilter updates for net-next

[Florian Westphal]

Hello,

[ sorry if you get this twice, wrong mail aliases in v1 ]

this PR contains updates for your *net-next* tree.

nftables updates:

1. Allow key existence checks with maps.
   At the moment the kernel requires userspace to pass a destination
   register for the associated value, make this optional so userspace
   can query if the key exists, just like with normal sets.

2. nftables maintains a counter per set that holds the number of
   elements.  This counter gets decremented on element removal,
   but its only incremented if the set has a upper maximum value.
   Increment unconditionally, this will allow us to update the
   maximum value later on.

3. At DCCP option maching, from Jeremy Sowden.

4. use struct_size macro, from Christophe JAILLET.

Conntrack:

5. Squash holes in struct nf_conntrack_expect, also Christophe JAILLET.

6. Allow clash resolution for GRE Protocol to avoid a packet drop,
   from Faicker Mo.

Flowtable:

Simplify route logic and split large functions into smaller
chunks, from Pablo Neira Ayuso.

The following changes since commit b50a8b0d57ab1ef11492171e98a030f48682eac3:

  net: openvswitch: Use struct_size() (2023-05-17 21:25:46 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git tags/nf-next-2023-05-18

for you to fetch changes up to e05b5362166b18a224c30502e81416e4d622d3e4:

  netfilter: flowtable: split IPv6 datapath in helper functions (2023-05-18 08:48:55 +0200)

----------------------------------------------------------------
Christophe JAILLET (2):
      netfilter: Reorder fields in 'struct nf_conntrack_expect'
      netfilter: nft_set_pipapo: Use struct_size()

Faicker Mo (1):
      netfilter: conntrack: allow insertion clash of gre protocol

Florian Westphal (2):
      netfilter: nf_tables: relax set/map validation checks
      netfilter: nf_tables: always increment set element count

Jeremy Sowden (1):
      netfilter: nft_exthdr: add boolean DCCP option matching

Pablo Neira Ayuso (3):
      netfilter: flowtable: simplify route logic
      netfilter: flowtable: split IPv4 datapath in helper functions
      netfilter: flowtable: split IPv6 datapath in helper functions

 include/net/netfilter/nf_conntrack_expect.h |  18 +--
 include/net/netfilter/nf_flow_table.h       |   4 +-
 include/uapi/linux/netfilter/nf_tables.h    |   2 +
 net/netfilter/nf_conntrack_proto_gre.c      |   1 +
 net/netfilter/nf_flow_table_core.c          |  24 +--
 net/netfilter/nf_flow_table_ip.c            | 231 ++++++++++++++++++----------
 net/netfilter/nf_tables_api.c               |  11 +-
 net/netfilter/nft_exthdr.c                  | 106 +++++++++++++
 net/netfilter/nft_flow_offload.c            |  12 +-
 net/netfilter/nft_lookup.c                  |  23 ++-
 net/netfilter/nft_set_pipapo.c              |   6 +-
 11 files changed, 303 insertions(+), 135 deletions(-)

[PATCH net-next 0/9] Netfilter updates for net-next

[Pablo Neira Ayuso]

Hi,

The following batch contains Netfilter updates for net-next:

Patch #1 fix checksum calculation in nfnetlink_queue with SCTP,
	 segment GSO packet since skb_zerocopy() does not support
	 GSO_BY_FRAGS, from Antonio Ojea.

Patch #2 extend nfnetlink_queue coverage to handle SCTP packets,
	 from Antonio Ojea.

Patch #3 uses consume_skb() instead of kfree_skb() in nfnetlink,
         from Donald Hunter.

Patch #4 adds a dedicate commit list for sets to speed up
	 intra-transaction lookups, from Florian Westphal.

Patch #5 skips removal of element from abort path for the pipapo
         backend, ditching the shadow copy of this datastructure
	 is sufficient.

Patch #6 moves nf_ct_netns_get() out of nf_conncount_init() to
	 let users of conncoiunt decide when to enable conntrack,
	 this is needed by openvswitch, from Xin Long.

Patch #7 pass context to all nft_parse_register_load() in
	 preparation for the next patch.

Patches #8 and #9 reject loads from uninitialized registers from
	 control plane to remove register initialization from
	 datapath. From Florian Westphal.

Please, pull these changes from:

  git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git nf-next-24-08-23

Thanks.

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

The following changes since commit 1bf8e07c382bd4f04ede81ecc05267a8ffd60999:

  dt-binding: ptp: fsl,ptp: add pci1957,ee02 compatible string for fsl,enetc-ptp (2024-08-19 09:48:53 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git tags/nf-next-24-08-23

for you to fetch changes up to c88baabf16d1ef74ab8832de9761226406af5507:

  netfilter: nf_tables: don't initialize registers in nft_do_chain() (2024-08-20 12:37:25 +0200)

----------------------------------------------------------------
netfilter pull request 24-08-23

----------------------------------------------------------------
Antonio Ojea (2):
      netfilter: nfnetlink_queue: unbreak SCTP traffic
      selftests: netfilter: nft_queue.sh: sctp coverage

Donald Hunter (1):
      netfilter: nfnetlink: convert kfree_skb to consume_skb

Florian Westphal (4):
      netfilter: nf_tables: store new sets in dedicated list
      netfilter: nf_tables: pass context structure to nft_parse_register_load
      netfilter: nf_tables: allow loads only when register is initialized
      netfilter: nf_tables: don't initialize registers in nft_do_chain()

Pablo Neira Ayuso (1):
      netfilter: nf_tables: do not remove elements if set backend implements .abort

Xin Long (1):
      netfilter: move nf_ct_netns_get out of nf_conncount_init

 include/net/netfilter/nf_conntrack_count.h         |  6 +-
 include/net/netfilter/nf_tables.h                  |  6 +-
 net/bridge/netfilter/nft_meta_bridge.c             |  2 +-
 net/core/dev.c                                     |  1 +
 net/ipv4/netfilter/nft_dup_ipv4.c                  |  4 +-
 net/ipv6/netfilter/nft_dup_ipv6.c                  |  4 +-
 net/netfilter/nf_conncount.c                       | 15 +---
 net/netfilter/nf_tables_api.c                      | 75 +++++++++++++++----
 net/netfilter/nf_tables_core.c                     |  2 +-
 net/netfilter/nfnetlink.c                          | 14 ++--
 net/netfilter/nfnetlink_queue.c                    | 12 ++-
 net/netfilter/nft_bitwise.c                        |  4 +-
 net/netfilter/nft_byteorder.c                      |  2 +-
 net/netfilter/nft_cmp.c                            |  6 +-
 net/netfilter/nft_ct.c                             |  2 +-
 net/netfilter/nft_dup_netdev.c                     |  2 +-
 net/netfilter/nft_dynset.c                         |  4 +-
 net/netfilter/nft_exthdr.c                         |  2 +-
 net/netfilter/nft_fwd_netdev.c                     |  6 +-
 net/netfilter/nft_hash.c                           |  2 +-
 net/netfilter/nft_lookup.c                         |  2 +-
 net/netfilter/nft_masq.c                           |  4 +-
 net/netfilter/nft_meta.c                           |  2 +-
 net/netfilter/nft_nat.c                            |  8 +-
 net/netfilter/nft_objref.c                         |  2 +-
 net/netfilter/nft_payload.c                        |  2 +-
 net/netfilter/nft_queue.c                          |  2 +-
 net/netfilter/nft_range.c                          |  2 +-
 net/netfilter/nft_redir.c                          |  4 +-
 net/netfilter/nft_tproxy.c                         |  4 +-
 net/netfilter/xt_connlimit.c                       | 15 +++-
 net/openvswitch/conntrack.c                        |  5 +-
 tools/testing/selftests/net/netfilter/config       |  2 +
 tools/testing/selftests/net/netfilter/nft_queue.sh | 85 +++++++++++++++++++++-
 34 files changed, 226 insertions(+), 84 deletions(-)

[PATCH net-next 0/9] netfilter: updates for net-next

[Florian Westphal]

Hi,

The following patchset contains Netfilter fixes for *net-next*:

Patches 1 to 4 add IP6IP6 tunneling acceleration to the flowtable
infrastructure.  Patch 5 extends test coverage for this.
From Lorenzo Bianconi.

Patch 6 removes a duplicated helper from xt_time extension, we can
use an existing helper for this, from Jinjie Ruan.

Patch 7 adds an rhashtable to nfnetink_queue to speed up out-of-order
verdict processing.  Before this list walk was required due to in-order
design assumption.

Patch 8 fixes an esoteric packet-drop problem with UDPGRO and nfqueue added
in v6.11. Patch 9 adds a test case for this.

Please, pull these changes from:
The following changes since commit 239f09e258b906deced5c2a7c1ac8aed301b558b:

  selftests: ptp: treat unsupported PHC operations as skip (2026-01-27 17:57:28 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git nf-next-26-01-28

for you to fetch changes up to f0ba90068f33a2d18fa4cc848ea7477d489194bf:

  selftests: netfilter: nft_queue.sh: add udp fraglist gro test case (2026-01-28 16:29:55 +0100)

----------------------------------------------------------------
netfilter pull request nf-next-26-01-28

----------------------------------------------------------------
Florian Westphal (2):
  netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation
  selftests: netfilter: nft_queue.sh: add udp fraglist gro test case

Jinjie Ruan (1):
  netfilter: xt_time: use is_leap_year() helper

Lorenzo Bianconi (5):
  netfilter: Add ctx pointer in nf_flow_skb_encap_protocol/nf_flow_ip4_tunnel_proto signature
  netfilter: Introduce tunnel metadata info in nf_flowtable_ctx struct
  netfilter: flowtable: Add IP6IP6 rx sw acceleration
  netfilter: flowtable: Add IP6IP6 tx sw acceleration
  selftests: netfilter: nft_flowtable.sh: Add IP6IP6 flowtable selftest

Scott Mitchell (1):
  netfilter: nfnetlink_queue: optimize verdict lookup with hash table

 include/net/netfilter/nf_queue.h              |   4 +
 net/ipv6/ip6_tunnel.c                         |  27 ++
 net/netfilter/nf_flow_table_ip.c              | 243 +++++++++++++---
 net/netfilter/nfnetlink_queue.c               | 263 ++++++++++++------
 net/netfilter/xt_time.c                       |   8 +-
 .../selftests/net/netfilter/nft_flowtable.sh  |  62 ++++-
 .../selftests/net/netfilter/nft_queue.sh      | 142 +++++++++-
 7 files changed, 612 insertions(+), 137 deletions(-)
-- 
2.52.0

Re: [PATCH net-next 0/9] netfilter: updates for net-next

[Jakub Kicinski]

On Wed, 28 Jan 2026 16:41:46 +0100 Florian Westphal wrote:
> Patches 1 to 4 add IP6IP6 tunneling acceleration to the flowtable
> infrastructure.  Patch 5 extends test coverage for this.
> From Lorenzo Bianconi.
> 
> Patch 6 removes a duplicated helper from xt_time extension, we can
> use an existing helper for this, from Jinjie Ruan.
> 
> Patch 7 adds an rhashtable to nfnetink_queue to speed up out-of-order
> verdict processing.  Before this list walk was required due to in-order
> design assumption.
> 
> Patch 8 fixes an esoteric packet-drop problem with UDPGRO and nfqueue added
> in v6.11. Patch 9 adds a test case for this.

Hi!

There's a UAF in the CI:

https://netdev-ctrl.bots.linux.dev/logs/vmksft/nf-dbg/results/494261/vm-crash-thr0-0

[  580.340726][T19113] sctp: Hash tables configured (bind 32/56)
[  601.749973][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  601.985349][    C2] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  602.191750][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  602.555469][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  602.895890][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  603.226543][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  603.435907][    C0] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  603.569421][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  603.672454][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  603.821679][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
[  618.553975][T19316] ==================================================================
[  618.554200][T19316] BUG: KASAN: slab-use-after-free in nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
[  618.554424][T19316] Write of size 1 at addr ff1100001cc9ae68 by task socat/19316
[  618.554600][T19316] 
[  618.554662][T19316] CPU: 2 UID: 0 PID: 19316 Comm: socat Not tainted 6.19.0-rc6-virtme #1 PREEMPT(full) 
[  618.554665][T19316] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  618.554667][T19316] Call Trace:
[  618.554669][T19316]  <TASK>
[  618.554670][T19316]  dump_stack_lvl+0x6f/0xa0
[  618.554678][T19316]  print_address_description.constprop.0+0x6e/0x300
[  618.554683][T19316]  print_report+0xfc/0x1fb
[  618.554684][T19316]  ? nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
[  618.554687][T19316]  ? __virt_addr_valid+0x1da/0x430
[  618.554691][T19316]  ? nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
[  618.554693][T19316]  kasan_report+0xe8/0x120
[  618.554697][T19316]  ? nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
[  618.554699][T19316]  nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
[  618.554702][T19316]  ? __nfqnl_enqueue_packet+0x470/0x470 [nfnetlink_queue]
[  618.554703][T19316]  ? nf_queue_entry_release_refs+0x230/0x240
[  618.554707][T19316]  ? __nf_queue+0x11f/0x1700
[  618.554709][T19316]  __nf_queue+0x50c/0x1700
[  618.554710][T19316]  ? nft_do_chain_inet+0xd8/0x3a0 [nf_tables]
[  618.554722][T19316]  ? nf_queue_entry_get_refs+0x390/0x390
[  618.554724][T19316]  nf_queue+0x18/0x50
[  618.554726][T19316]  nf_hook_slow+0x138/0x1d0
[  618.554729][T19316]  __ip_local_out+0x41f/0x8d0
[  618.554731][T19316]  ? ip_output+0x650/0x650
[  618.554732][T19316]  ? lock_acquire.part.0+0xbc/0x260
[  618.554735][T19316]  ? find_held_lock+0x2b/0x80
[  618.554737][T19316]  ? ip_append_data.part.0+0x1a0/0x1a0
[  618.554740][T19316]  ? ip4_dst_hoplimit+0x15b/0x320
[  618.554742][T19316]  __ip_queue_xmit+0x73f/0x1660
[  618.554744][T19316]  sctp_packet_transmit+0x655/0x1070 [sctp]
[  618.554757][T19316]  sctp_outq_flush_transports+0x321/0x6c0 [sctp]
[  618.554768][T19316]  sctp_outq_flush+0x125/0x190 [sctp]
[  618.554775][T19316]  ? lock_acquire.part.0+0xbc/0x260
[  618.554777][T19316]  ? sctp_outq_flush_data+0x1950/0x1950 [sctp]
[  618.554784][T19316]  ? sctp_outq_tail+0x2b8/0xa20 [sctp]
[  618.554791][T19316]  sctp_cmd_interpreter.isra.0+0x40e/0x4f50 [sctp]
[  618.554801][T19316]  ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp]
[  618.554807][T19316]  ? rcu_lockdep_current_cpu_online+0x39/0x1b0
[  618.554812][T19316]  sctp_side_effects+0xcf/0x230 [sctp]
[  618.554819][T19316]  ? sctp_cmd_interpreter.isra.0+0x4f50/0x4f50 [sctp]
[  618.554825][T19316]  ? __lock_acquire+0x577/0xc10
[  618.554828][T19316]  ? br_deinit+0x5b0/0x5b0 [bridge]
[  618.554836][T19316]  sctp_do_sm+0x1a0/0x4e0 [sctp]
[  618.554844][T19316]  ? sctp_cname+0x1c0/0x1c0 [sctp]
[  618.554851][T19316]  ? __lock_release.isra.0+0x59/0x170
[  618.554853][T19316]  ? sctp_do_8_2_transport_strike.isra.0+0x1160/0x1160 [sctp]
[  618.554860][T19316]  ? __might_fault+0x97/0x140
[  618.554866][T19316]  ? sctp_datamsg_from_user+0x677/0x1140 [sctp]
[  618.554875][T19316]  ? skb_set_owner_w+0x27e/0x610
[  618.554879][T19316]  ? sock_recv_errqueue+0x4a0/0x4a0
[  618.554881][T19316]  sctp_primitive_SEND+0x82/0xe0 [sctp]
[  618.554889][T19316]  sctp_sendmsg_to_asoc+0x9d0/0x1420 [sctp]
[  618.554898][T19316]  ? sctp_close+0x850/0x850 [sctp]
[  618.554904][T19316]  ? mark_held_locks+0x40/0x70
[  618.554907][T19316]  sctp_sendmsg+0x624/0xd70 [sctp]
[  618.554915][T19316]  ? sctp_sendmsg_new_asoc+0x720/0x720 [sctp]
[  618.554921][T19316]  ? current_time+0x83/0x300
[  618.554924][T19316]  ? new_sync_write+0x6f0/0x6f0
[  618.554927][T19316]  ? make_vfsuid+0xe0/0xe0
[  618.554930][T19316]  ? ovl_path_next+0x760/0x760
[  618.554934][T19316]  ? atime_needs_update+0x27f/0x5d0
[  618.554937][T19316]  sock_write_iter+0x281/0x4d0
[  618.554938][T19316]  ? backing_file_read_iter+0x50e/0x730
[  618.554942][T19316]  ? ____sys_recvmsg+0x6b0/0x6b0
[  618.554945][T19316]  ? ovl_mmap+0x270/0x270
[  618.554947][T19316]  ? ____sys_recvmsg+0x6b0/0x6b0
[  618.554948][T19316]  new_sync_write+0x3c5/0x6f0
[  618.554950][T19316]  ? new_sync_read+0x24f/0x6f0
[  618.554952][T19316]  ? new_sync_read+0x6f0/0x6f0
[  618.554954][T19316]  ? generic_atomic_write_valid+0x150/0x150
[  618.554956][T19316]  ? __set_current_blocked+0x110/0x110
[  618.554959][T19316]  ? find_held_lock+0x2b/0x80
[  618.554961][T19316]  ? do_pselect.constprop.0+0x14e/0x1f0
[  618.554964][T19316]  vfs_write+0x65e/0xbb0
[  618.554966][T19316]  ? vfs_read+0x3cc/0x790
[  618.554968][T19316]  ksys_write+0x17e/0x200
[  618.554970][T19316]  ? __ia32_sys_read+0xc0/0xc0
[  618.554972][T19316]  ? rcu_is_watching+0x15/0xd0
[  618.554974][T19316]  do_syscall_64+0xbd/0xfc0
[  618.554979][T19316]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
[  618.554981][T19316] RIP: 0033:0x7fd5f9750c5e
[  618.554984][T19316] Code: 4d 89 d8 e8 34 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa
[  618.554987][T19316] RSP: 002b:00007fffca8a36c0 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[  618.554990][T19316] RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 00007fd5f9750c5e
[  618.554992][T19316] RDX: 0000000000002000 RSI: 000055fcf0fd4000 RDI: 0000000000000007
[  618.554993][T19316] RBP: 00007fffca8a36d0 R08: 0000000000000000 R09: 0000000000000000
[  618.554994][T19316] R10: 0000000000000000 R11: 0000000000000202 R12: 000055fcf0fd4000
[  618.554995][T19316] R13: 0000000000002000 R14: 000055fcf0fd4000 R15: 0000000000000007
[  618.554997][T19316]  </TASK>
[  618.554998][T19316] 
[  618.565908][T19316] Allocated by task 19316:
[  618.566029][T19316]  kasan_save_stack+0x30/0x50
[  618.566144][T19316]  kasan_save_track+0x14/0x30
[  618.566258][T19316]  __kasan_kmalloc+0x7b/0x90
[  618.566369][T19316]  __kmalloc_noprof+0x2cd/0x820
[  618.566479][T19316]  __nf_queue+0x11f/0x1700
[  618.566589][T19316]  nf_queue+0x18/0x50
[  618.566671][T19316]  nf_hook_slow+0x138/0x1d0
[  618.566784][T19316]  __ip_local_out+0x41f/0x8d0
[  618.566892][T19316]  __ip_queue_xmit+0x73f/0x1660
[  618.567003][T19316]  sctp_packet_transmit+0x655/0x1070 [sctp]
[  618.567148][T19316]  sctp_outq_flush_transports+0x321/0x6c0 [sctp]
[  618.567294][T19316]  sctp_outq_flush+0x125/0x190 [sctp]
[  618.567408][T19316]  sctp_cmd_interpreter.isra.0+0x40e/0x4f50 [sctp]
[  618.567552][T19316]  sctp_side_effects+0xcf/0x230 [sctp]
[  618.567670][T19316]  sctp_do_sm+0x1a0/0x4e0 [sctp]
[  618.567785][T19316]  sctp_primitive_SEND+0x82/0xe0 [sctp]
[  618.567899][T19316]  sctp_sendmsg_to_asoc+0x9d0/0x1420 [sctp]
[  618.568040][T19316]  sctp_sendmsg+0x624/0xd70 [sctp]
[  618.568160][T19316]  sock_write_iter+0x281/0x4d0
[  618.568270][T19316]  new_sync_write+0x3c5/0x6f0
[  618.568380][T19316]  vfs_write+0x65e/0xbb0
[  618.568464][T19316]  ksys_write+0x17e/0x200
[  618.568546][T19316]  do_syscall_64+0xbd/0xfc0
[  618.568656][T19316]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
[  618.568794][T19316] 
[  618.568851][T19316] Freed by task 19314:
[  618.568935][T19316]  kasan_save_stack+0x30/0x50
[  618.569047][T19316]  kasan_save_track+0x14/0x30
[  618.569160][T19316]  kasan_save_free_info+0x3b/0x60
[  618.569273][T19316]  __kasan_slab_free+0x43/0x70
[  618.569390][T19316]  kfree+0x119/0x580
[  618.569472][T19316]  nfqnl_reinject+0x7f/0x3d0 [nfnetlink_queue]
[  618.569610][T19316]  nfqnl_recv_verdict+0x76f/0xfd3 [nfnetlink_queue]
[  618.569747][T19316]  nfnetlink_rcv_msg+0x49b/0xf00
[  618.569859][T19316]  netlink_rcv_skb+0x123/0x380
[  618.569970][T19316]  nfnetlink_rcv+0x166/0x4a0
[  618.570080][T19316]  netlink_unicast+0x4a3/0x770
[  618.570195][T19316]  netlink_sendmsg+0x735/0xc60
[  618.570307][T19316]  __sys_sendto+0x24e/0x360
[  618.570419][T19316]  __x64_sys_sendto+0xe4/0x1f0
[  618.570529][T19316]  do_syscall_64+0xbd/0xfc0
[  618.570640][T19316]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
[  618.570776][T19316] 
[  618.570833][T19316] The buggy address belongs to the object at ff1100001cc9ae00
[  618.570833][T19316]  which belongs to the cache kmalloc-128 of size 128
[  618.571105][T19316] The buggy address is located 104 bytes inside of
[  618.571105][T19316]  freed 128-byte region [ff1100001cc9ae00, ff1100001cc9ae80)
[  618.571381][T19316] 
[  618.571438][T19316] The buggy address belongs to the physical page:
[  618.571573][T19316] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xff1100001cc9be80 pfn:0x1cc9a
[  618.571803][T19316] head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[  618.571972][T19316] flags: 0x80000000000240(workingset|head|node=0|zone=1)
[  618.572115][T19316] page_type: f5(slab)
[  618.572206][T19316] raw: 0080000000000240 ff1100000103ce40 ffd4000000048090 ff11000001032a88
[  618.572404][T19316] raw: ff1100001cc9be80 0000000000150011 00000000f5000000 0000000000000000
[  618.572603][T19316] head: 0080000000000240 ff1100000103ce40 ffd4000000048090 ff11000001032a88
[  618.572798][T19316] head: ff1100001cc9be80 0000000000150011 00000000f5000000 0000000000000000
[  618.572994][T19316] head: 0080000000000001 ffd4000000732681 00000000ffffffff 00000000ffffffff
[  618.573191][T19316] head: ff1100001cc9bf10 0000000000000000 00000000ffffffff 0000000000000000
[  618.573390][T19316] page dumped because: kasan: bad access detected
[  618.573527][T19316] 
[  618.573584][T19316] Memory state around the buggy address:
[  618.573693][T19316]  ff1100001cc9ad00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  618.573856][T19316]  ff1100001cc9ad80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  618.574015][T19316] >ff1100001cc9ae00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  618.574179][T19316]                                                           ^
[  618.574343][T19316]  ff1100001cc9ae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  618.574504][T19316]  ff1100001cc9af00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  618.574672][T19316] ==================================================================
[  618.574903][T19316] Disabling lock debugging due to kernel taint

Re: [PATCH net-next 0/9] netfilter: updates for net-next

[Florian Westphal]

Jakub Kicinski <kuba@kernel.org> wrote:
> On Wed, 28 Jan 2026 16:41:46 +0100 Florian Westphal wrote:
> > Patches 1 to 4 add IP6IP6 tunneling acceleration to the flowtable
> > infrastructure.  Patch 5 extends test coverage for this.
> > From Lorenzo Bianconi.
> > 
> > Patch 6 removes a duplicated helper from xt_time extension, we can
> > use an existing helper for this, from Jinjie Ruan.
> > 
> > Patch 7 adds an rhashtable to nfnetink_queue to speed up out-of-order
> > verdict processing.  Before this list walk was required due to in-order
> > design assumption.
> > 
> > Patch 8 fixes an esoteric packet-drop problem with UDPGRO and nfqueue added
> > in v6.11. Patch 9 adds a test case for this.
> 
> Hi!
> 
> There's a UAF in the CI:
> 
> https://netdev-ctrl.bots.linux.dev/logs/vmksft/nf-dbg/results/494261/vm-crash-thr0-0
> 
> [  580.340726][T19113] sctp: Hash tables configured (bind 32/56)
> [  601.749973][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  601.985349][    C2] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  602.191750][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  602.555469][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  602.895890][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  603.226543][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  603.435907][    C0] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  603.569421][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  603.672454][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  603.821679][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> [  618.553975][T19316] ==================================================================
> [  618.554200][T19316] BUG: KASAN: slab-use-after-free in nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
> [  618.554424][T19316] Write of size 1 at addr ff1100001cc9ae68 by task socat/19316
> [  618.554600][T19316] 

Did not occur here during local testing :-(

Should I send a v2 without the last two patches or will you pull and
discard the last two changes?

Re: [PATCH net-next 0/9] netfilter: updates for net-next

[Florian Westphal]

Florian Westphal <fw@strlen.de> wrote:
> Jakub Kicinski <kuba@kernel.org> wrote:
> > [  580.340726][T19113] sctp: Hash tables configured (bind 32/56)
> > [  601.749973][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  601.985349][    C2] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  602.191750][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  602.555469][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  602.895890][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  603.226543][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  603.435907][    C0] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  603.569421][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  603.672454][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  603.821679][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
> > [  618.553975][T19316] ==================================================================
> > [  618.554200][T19316] BUG: KASAN: slab-use-after-free in nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
> > [  618.554424][T19316] Write of size 1 at addr ff1100001cc9ae68 by task socat/19316
> > [  618.554600][T19316] 
> 
> Did not occur here during local testing :-(
> 
> Should I send a v2 without the last two patches or will you pull and
> discard the last two changes?

Alternatively you can also pull this:

  https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git tags/nf-next-26-01-29

Which is the same series but without the last two patches, i.e. up to
e19079adcd26a25d7d3e586b1837493361fdf8b6:

  netfilter: nfnetlink_queue: optimize verdict lookup with hash table (2026-01-29 09:52:07 +0100)

----------------------------------------------------------------
netfilter pull request nf-next-26-01-29

----------------------------------------------------------------
Jinjie Ruan (1):
      netfilter: xt_time: use is_leap_year() helper

Lorenzo Bianconi (5):
      netfilter: Add ctx pointer in nf_flow_skb_encap_protocol/nf_flow_ip4_tunnel_proto signature
      netfilter: Introduce tunnel metadata info in nf_flowtable_ctx struct
      netfilter: flowtable: Add IP6IP6 rx sw acceleration
      netfilter: flowtable: Add IP6IP6 tx sw acceleration
      selftests: netfilter: nft_flowtable.sh: Add IP6IP6 flowtable selftest

Scott Mitchell (1):
      netfilter: nfnetlink_queue: optimize verdict lookup with hash table

6 files changed, 408 insertions(+), 81 deletions(-)

Re: [PATCH net-next 0/9] netfilter: updates for net-next

[Paolo Abeni]

On 1/29/26 11:08 AM, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
>> Jakub Kicinski <kuba@kernel.org> wrote:
>>> [  580.340726][T19113] sctp: Hash tables configured (bind 32/56)
>>> [  601.749973][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  601.985349][    C2] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  602.191750][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  602.555469][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  602.895890][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  603.226543][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  603.435907][    C0] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  603.569421][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  603.672454][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  603.821679][    C1] TCP: request_sock_TCP: Possible SYN flooding on port 127.0.0.1:23456. Sending cookies.
>>> [  618.553975][T19316] ==================================================================
>>> [  618.554200][T19316] BUG: KASAN: slab-use-after-free in nfqnl_enqueue_packet+0x8f1/0x9e0 [nfnetlink_queue]
>>> [  618.554424][T19316] Write of size 1 at addr ff1100001cc9ae68 by task socat/19316
>>> [  618.554600][T19316] 
>>
>> Did not occur here during local testing :-(
>>
>> Should I send a v2 without the last two patches or will you pull and
>> discard the last two changes?
> 
> Alternatively you can also pull this:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git tags/nf-next-26-01-29
> 
> Which is the same series but without the last two patches, i.e. up to
> e19079adcd26a25d7d3e586b1837493361fdf8b6:
> 
>   netfilter: nfnetlink_queue: optimize verdict lookup with hash table (2026-01-29 09:52:07 +0100)

Would you mind sending a formal v2 of the PR, so that the CI catches it
up and it's properly tracked in PW?

Thanks!

Paolo

[PATCH net-next 0/9] netfilter: updates for net-next

[Florian Westphal]

Hi,

The following patchset contains Netfilter fixes for *net-next*,
including IPVS updates from and via Julian Anastasov.

First updates for IPVS. From Julians cover-letter:

* Convert the global __ip_vs_mutex to per-net service_mutex and
  switch the service tables to be per-net, cowork by Jiejian Wu and
  Dust Li

* Convert some code that walks the service lists to use RCU instead of
  the service_mutex

* We used two tables for services (non-fwmark and fwmark), merge them
  into single svc_table

* The list for unavailable destinations (dest_trash) holds dsts and
  thus dev references causing extra work for the ip_vs_dst_event() dev
  notifier handler. Change this by dropping the reference when dest
  is removed and saved into dest_trash. The dest_trash will need more
  changes to make it light for lookups. TODO.

* On new connection we can do multiple lookups for services by trying
  different fallback options. Add more counters for service types, so
  that we can avoid unneeded lookups for services.

* The no_cport and dropentry counters can be per-net and also we can
  avoid extra conn lookups

Then, a few cleanups for nf_tables:

* keep BH enabled during nft_set_rbtree inserts, this is possible because the
  root lock is now only taken from control plane.
* toss a few EXPORT_SYMBOLs from nf_tables; these were historic
  leftovers from back in the day when e.g. set backends were still
  residing in their own modules.
* remove the register tracking infra from nftables.  It was disabled
  years ago in 5.18 and there are no plans to salvage this work; the
  idea was good (remove redundant register stores), but there is just
  one too many pitfalls, and better rule structuring (verdict maps)
  largely avoids the scenarios where this would have helped.

Florian Westphal (3):
  netfilter: nft_set_rbtree: don't disable bh when acquiring tree lock
  netfilter: nf_tables: drop obsolete EXPORT_SYMBOLs
  netfilter: nf_tables: remove register tracking infrastructure

Jiejian Wu (1):
  ipvs: make ip_vs_svc_table and ip_vs_svc_fwm_table per netns

Julian Anastasov (5):
  ipvs: some service readers can use RCU
  ipvs: use single svc table
  ipvs: do not keep dest_dst after dest is removed
  ipvs: use more counters to avoid service lookups
  ipvs: no_cport and dropentry counters can be per-net

 include/net/ip_vs.h                      |  39 ++-
 include/net/netfilter/nf_tables.h        |  32 --
 include/net/netfilter/nft_fib.h          |   2 -
 include/net/netfilter/nft_meta.h         |   3 -
 net/bridge/netfilter/nft_meta_bridge.c   |  20 --
 net/bridge/netfilter/nft_reject_bridge.c |   1 -
 net/ipv4/netfilter/nft_dup_ipv4.c        |   1 -
 net/ipv4/netfilter/nft_fib_ipv4.c        |   2 -
 net/ipv4/netfilter/nft_reject_ipv4.c     |   1 -
 net/ipv6/netfilter/nft_dup_ipv6.c        |   1 -
 net/ipv6/netfilter/nft_fib_ipv6.c        |   2 -
 net/ipv6/netfilter/nft_reject_ipv6.c     |   1 -
 net/netfilter/ipvs/ip_vs_conn.c          |  64 ++--
 net/netfilter/ipvs/ip_vs_core.c          |   2 +-
 net/netfilter/ipvs/ip_vs_ctl.c           | 368 ++++++++---------------
 net/netfilter/ipvs/ip_vs_est.c           |  18 +-
 net/netfilter/ipvs/ip_vs_xmit.c          |  12 +-
 net/netfilter/nf_tables_api.c            |  78 -----
 net/netfilter/nft_bitwise.c              | 104 -------
 net/netfilter/nft_byteorder.c            |  11 -
 net/netfilter/nft_cmp.c                  |   3 -
 net/netfilter/nft_compat.c               |  10 -
 net/netfilter/nft_connlimit.c            |   1 -
 net/netfilter/nft_counter.c              |   1 -
 net/netfilter/nft_ct.c                   |  46 ---
 net/netfilter/nft_dup_netdev.c           |   1 -
 net/netfilter/nft_dynset.c               |   1 -
 net/netfilter/nft_exthdr.c               |  34 ---
 net/netfilter/nft_fib.c                  |  42 ---
 net/netfilter/nft_fib_inet.c             |   1 -
 net/netfilter/nft_fib_netdev.c           |   1 -
 net/netfilter/nft_flow_offload.c         |   1 -
 net/netfilter/nft_fwd_netdev.c           |   2 -
 net/netfilter/nft_hash.c                 |  36 ---
 net/netfilter/nft_immediate.c            |  12 -
 net/netfilter/nft_last.c                 |   1 -
 net/netfilter/nft_limit.c                |   2 -
 net/netfilter/nft_log.c                  |   1 -
 net/netfilter/nft_lookup.c               |  12 -
 net/netfilter/nft_masq.c                 |   3 -
 net/netfilter/nft_meta.c                 |  45 ---
 net/netfilter/nft_nat.c                  |   2 -
 net/netfilter/nft_numgen.c               |  22 --
 net/netfilter/nft_objref.c               |   2 -
 net/netfilter/nft_osf.c                  |  25 --
 net/netfilter/nft_payload.c              |  47 ---
 net/netfilter/nft_queue.c                |   2 -
 net/netfilter/nft_quota.c                |   1 -
 net/netfilter/nft_range.c                |   1 -
 net/netfilter/nft_redir.c                |   3 -
 net/netfilter/nft_reject_inet.c          |   1 -
 net/netfilter/nft_reject_netdev.c        |   1 -
 net/netfilter/nft_rt.c                   |   1 -
 net/netfilter/nft_set_rbtree.c           |  23 +-
 net/netfilter/nft_socket.c               |  26 --
 net/netfilter/nft_synproxy.c             |   1 -
 net/netfilter/nft_tproxy.c               |   1 -
 net/netfilter/nft_tunnel.c               |  26 --
 net/netfilter/nft_xfrm.c                 |  27 --
 59 files changed, 221 insertions(+), 1009 deletions(-)

-- 
2.52.0

Re: [PATCH net-next 0/9] netfilter: updates for net-next

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 24 Feb 2026 21:50:39 +0100 you wrote:
> Hi,
> 
> The following patchset contains Netfilter fixes for *net-next*,
> including IPVS updates from and via Julian Anastasov.
> 
> First updates for IPVS. From Julians cover-letter:
> 
> [...]

Here is the summary with links:
  - [net-next,1/9] ipvs: make ip_vs_svc_table and ip_vs_svc_fwm_table per netns
    https://git.kernel.org/netdev/net-next/c/74455a5b4326
  - [net-next,2/9] ipvs: some service readers can use RCU
    https://git.kernel.org/netdev/net-next/c/3de0ec2873ea
  - [net-next,3/9] ipvs: use single svc table
    https://git.kernel.org/netdev/net-next/c/b24ae1a387e4
  - [net-next,4/9] ipvs: do not keep dest_dst after dest is removed
    https://git.kernel.org/netdev/net-next/c/40fb72209fd8
  - [net-next,5/9] ipvs: use more counters to avoid service lookups
    https://git.kernel.org/netdev/net-next/c/c59bd9e62e06
  - [net-next,6/9] ipvs: no_cport and dropentry counters can be per-net
    https://git.kernel.org/netdev/net-next/c/09b71fb45946
  - [net-next,7/9] netfilter: nft_set_rbtree: don't disable bh when acquiring tree lock
    https://git.kernel.org/netdev/net-next/c/3aea466a4399
  - [net-next,8/9] netfilter: nf_tables: drop obsolete EXPORT_SYMBOLs
    https://git.kernel.org/netdev/net-next/c/b6461103e01a
  - [net-next,9/9] netfilter: nf_tables: remove register tracking infrastructure
    https://git.kernel.org/netdev/net-next/c/6b94d081f81d

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

[PATCH net-next 0/9] Netfilter updates for net-next

[Pablo Neira Ayuso]

Hi,

The following patchset contains Netfilter updates for net-next:

1) Update conncount to use the original tuple after ct lookup to ensure
   consistent counting, from Fernando F. Mancera.

2) Remove redundant net_device field in info structure that helps
   parse the flowtable path discovery.

3) Move net_device to flowtable check to the flowtable discovery
   path parser. This is preparation work to pass the tunnel dst_entry
   via .fill_forward_path.

4) Update DSA .fill_forward_path to break at the user DSA, since
   the conduit DSA is not used in the datapath. This slighly simplifies
   the flowtable path discovery parser.

5) Do not advance index in the path stack prematurely, otherwise
   it points to uninitialized slots on error. Not an issue currently
   but it could be once tunnel dst_entry is passed via .fill_forward_path.

6) Pass the tunnel dst_entry via dev_fill_forward_path().

7) Update ipip and ip6ip6 tunnels to pass the dst_entry through
   dev_fill_forward_path().

8) Call skb_valid_dst() before accessing skb_dst() to ensure dst_entry
   is not a template.

9) Use UNACK timeout when RST packet does not match the expected
   window while in ESTABLISHED state, the existing approach the CLOSE
   state timeout which is only 10 seconds. Adopt a more conservative
   timeout by default for this case.

Please, pull these changes from:

  git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git nf-next-26-07-31

Thanks.

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

The following changes since commit 2fbade66245059c78daeaccfce13ecf499fffb51:

  Merge branch 'net-mctp-usb-add-support-for-mctp-over-usb-v1-1' (2026-07-30 16:55:02 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git tags/nf-next-26-07-31

for you to fetch changes up to bf80e6802273a900311b44e47c9b1a59c6d2473c:

  netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets (2026-07-31 14:47:03 +0200)

----------------------------------------------------------------
netfilter pull request 26-07-31

----------------------------------------------------------------
Fernando Fernandez Mancera (1):
      netfilter: conncount: normalize tuple and zone on successful ct lookup

Minghao Zhang (1):
      netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets

Pablo Neira Ayuso (7):
      netfilter: flowtable: consolidate net_device field in nft_forward_info struct
      netfilter: flowtable: consolidate flowtable device check
      net: dsa: stop at the user device in .fill_forward_path
      net: do not advance stack index from dev_fwd_path()
      net: pass dst via net_device_path in dev_fill_forward_path()
      netfilter: flowtable: release tunnel route on error when building forward path
      netfilter: nf_tables: call skb_valid_dst() before skb_dst()

 drivers/net/ethernet/airoha/airoha_ppe.c        |  10 ++-
 drivers/net/ethernet/mediatek/mtk_ppe_offload.c |  10 ++-
 include/linux/netdevice.h                       |   2 +
 net/core/dev.c                                  |  44 +++++++---
 net/dsa/user.c                                  |   3 +-
 net/ipv4/ipip.c                                 |   2 +-
 net/ipv4/netfilter/nf_reject_ipv4.c             |   6 +-
 net/ipv6/ip6_tunnel.c                           |   4 +-
 net/ipv6/netfilter/nf_reject_ipv6.c             |   8 +-
 net/netfilter/nf_conncount.c                    |   2 +
 net/netfilter/nf_conntrack_proto_tcp.c          |   5 +-
 net/netfilter/nf_flow_table_path.c              | 103 ++++++++----------------
 net/netfilter/nft_meta.c                        |   6 +-
 net/netfilter/nft_rt.c                          |   6 +-
 net/netfilter/nft_xfrm.c                        |   9 ++-
 15 files changed, 121 insertions(+), 99 deletions(-)

[PATCH net-next 1/9] netfilter: conncount: normalize tuple and zone on successful ct lookup

[Pablo Neira Ayuso]

From: Fernando Fernandez Mancera <fmancera@suse.de>

When get_ct_or_tuple_from_skb() falls back to looking for a connection
via nf_conntrack_find_get(), a successful lookup sets ct but leaves
tuple and zone unupdated.

If the packet belongs to a reply flow, tuple will remain in the reply
direction. As conncount relies on the original direction tuple to count
the connections consistenly, passing an unnormalized reply tuple could
lead to problems.

Fix this by making sure that tuple and zone are normalized.

Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nf_conncount.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/nf_conncount.c b/net/netfilter/nf_conncount.c
index e9ea6d9466e7..85487f92af50 100644
--- a/net/netfilter/nf_conncount.c
+++ b/net/netfilter/nf_conncount.c
@@ -158,6 +158,8 @@ static bool get_ct_or_tuple_from_skb(struct net *net,
 		return true;
 
 	found_ct = nf_ct_tuplehash_to_ctrack(h);
+	*tuple = found_ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
+	*zone = nf_ct_zone(found_ct);
 	*refcounted = true;
 	*ct = found_ct;
 
-- 
2.47.3

[PATCH net-next 2/9] netfilter: flowtable: consolidate net_device field in nft_forward_info struct

[Pablo Neira Ayuso]

info->indev and info->outdev refer to the same device, a single
info->dev field is sufficient.

While at it, remove unused router parameter from the flowtable path
discovery function.

Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nf_flow_table_path.c | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/net/netfilter/nf_flow_table_path.c b/net/netfilter/nf_flow_table_path.c
index 98c03b487f52..261bb44d08eb 100644
--- a/net/netfilter/nf_flow_table_path.c
+++ b/net/netfilter/nf_flow_table_path.c
@@ -42,8 +42,7 @@ static bool nft_is_valid_ether_device(const struct net_device *dev)
 	return true;
 }
 
-static int nft_dev_fill_forward_path(const struct nf_flow_route *route,
-				     const struct dst_entry *dst_cache,
+static int nft_dev_fill_forward_path(const struct dst_entry *dst_cache,
 				     const struct nf_conn *ct,
 				     enum ip_conntrack_dir dir, u8 *ha,
 				     struct net_device_path_stack *stack)
@@ -76,8 +75,7 @@ static int nft_dev_fill_forward_path(const struct nf_flow_route *route,
 }
 
 struct nft_forward_info {
-	const struct net_device *indev;
-	const struct net_device *outdev;
+	const struct net_device *dev;
 	struct id {
 		__u16	id;
 		__be16	proto;
@@ -109,7 +107,7 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 		case DEV_PATH_VLAN:
 		case DEV_PATH_PPPOE:
 		case DEV_PATH_TUN:
-			info->indev = path->dev;
+			info->dev = path->dev;
 			if (is_zero_ether_addr(info->h_source))
 				memcpy(info->h_source, path->dev->dev_addr, ETH_ALEN);
 
@@ -179,10 +177,9 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 			return -1;
 		}
 	}
-	info->outdev = info->indev;
 
 	if (nf_flowtable_hw_offload(flowtable) &&
-	    nft_is_valid_ether_device(info->indev))
+	    nft_is_valid_ether_device(info->dev))
 		info->xmit_type = FLOW_OFFLOAD_XMIT_DIRECT;
 
 	return 0;
@@ -255,17 +252,16 @@ static int nft_dev_forward_path(const struct nft_pktinfo *pkt,
 	unsigned char ha[ETH_ALEN];
 	int i;
 
-	if (nft_dev_fill_forward_path(route, dst, ct, dir, ha, &stack) < 0 ||
+	if (nft_dev_fill_forward_path(dst, ct, dir, ha, &stack) < 0 ||
 	    nft_dev_path_info(&stack, &info, ha, &ft->data) < 0)
 		return -ENOENT;
 
-	if (!nft_flowtable_find_dev(info.indev, ft))
+	if (!nft_flowtable_find_dev(info.dev, ft))
 		return -ENOENT;
 
-	if (info.outdev)
-		route->tuple[dir].out.ifindex = info.outdev->ifindex;
+	route->tuple[!dir].in.ifindex = info.dev->ifindex;
+	route->tuple[dir].out.ifindex = info.dev->ifindex;
 
-	route->tuple[!dir].in.ifindex = info.indev->ifindex;
 	for (i = 0; i < info.num_encaps; i++) {
 		route->tuple[!dir].in.encap[i].id = info.encap[i].id;
 		route->tuple[!dir].in.encap[i].proto = info.encap[i].proto;
-- 
2.47.3

[PATCH net-next 3/9] netfilter: flowtable: consolidate flowtable device check

[Pablo Neira Ayuso]

Check that device belongs to the flowtable right after the flowtable
discovery path. This is a preparation patch to obtain the dst entry
from the .fill_forward_path in tunnels.

No functional changes are intended.

Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nf_flow_table_path.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/net/netfilter/nf_flow_table_path.c b/net/netfilter/nf_flow_table_path.c
index 261bb44d08eb..8f04a4487897 100644
--- a/net/netfilter/nf_flow_table_path.c
+++ b/net/netfilter/nf_flow_table_path.c
@@ -90,9 +90,12 @@ struct nft_forward_info {
 	enum flow_offload_xmit_type xmit_type;
 };
 
+static bool nft_flowtable_find_dev(const struct net_device *dev,
+				   struct nft_flowtable *ft);
+
 static int nft_dev_path_info(const struct net_device_path_stack *stack,
 			     struct nft_forward_info *info,
-			     unsigned char *ha, struct nf_flowtable *flowtable)
+			     unsigned char *ha, struct nft_flowtable *ft)
 {
 	const struct net_device_path *path;
 	int i;
@@ -178,10 +181,13 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 		}
 	}
 
-	if (nf_flowtable_hw_offload(flowtable) &&
+	if (nf_flowtable_hw_offload(&ft->data) &&
 	    nft_is_valid_ether_device(info->dev))
 		info->xmit_type = FLOW_OFFLOAD_XMIT_DIRECT;
 
+	if (!nft_flowtable_find_dev(info->dev, ft))
+		return -1;
+
 	return 0;
 }
 
@@ -253,10 +259,7 @@ static int nft_dev_forward_path(const struct nft_pktinfo *pkt,
 	int i;
 
 	if (nft_dev_fill_forward_path(dst, ct, dir, ha, &stack) < 0 ||
-	    nft_dev_path_info(&stack, &info, ha, &ft->data) < 0)
-		return -ENOENT;
-
-	if (!nft_flowtable_find_dev(info.dev, ft))
+	    nft_dev_path_info(&stack, &info, ha, ft) < 0)
 		return -ENOENT;
 
 	route->tuple[!dir].in.ifindex = info.dev->ifindex;
-- 
2.47.3

[PATCH net-next 4/9] net: dsa: stop at the user device in .fill_forward_path

[Pablo Neira Ayuso]

The flowtable path discovery stops at the DSA user device when setting
up the forward path. Let's just report there is no more devices after
the DSA user port through the .fill_forward_path interface.

No functional changes are intended.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/dsa/user.c                     | 3 +--
 net/netfilter/nf_flow_table_path.c | 7 ++-----
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/net/dsa/user.c b/net/dsa/user.c
index 03c7af6abe18..4065c6ee6fc6 100644
--- a/net/dsa/user.c
+++ b/net/dsa/user.c
@@ -2547,14 +2547,13 @@ static int dsa_user_fill_forward_path(struct net_device_path_ctx *ctx,
 				      struct net_device_path *path)
 {
 	struct dsa_port *dp = dsa_user_to_port(ctx->dev);
-	struct net_device *conduit = dsa_port_to_conduit(dp);
 	struct dsa_port *cpu_dp = dp->cpu_dp;
 
 	path->dev = ctx->dev;
 	path->type = DEV_PATH_DSA;
 	path->dsa.proto = cpu_dp->tag_ops->proto;
 	path->dsa.port = dp->index;
-	ctx->dev = conduit;
+	ctx->dev = NULL;
 
 	return 0;
 }
diff --git a/net/netfilter/nf_flow_table_path.c b/net/netfilter/nf_flow_table_path.c
index 8f04a4487897..004dc75ac357 100644
--- a/net/netfilter/nf_flow_table_path.c
+++ b/net/netfilter/nf_flow_table_path.c
@@ -114,12 +114,9 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 			if (is_zero_ether_addr(info->h_source))
 				memcpy(info->h_source, path->dev->dev_addr, ETH_ALEN);
 
-			if (path->type == DEV_PATH_ETHERNET)
+			if (path->type == DEV_PATH_ETHERNET ||
+			    path->type == DEV_PATH_DSA)
 				break;
-			if (path->type == DEV_PATH_DSA) {
-				i = stack->num_paths;
-				break;
-			}
 
 			/* DEV_PATH_VLAN, DEV_PATH_PPPOE and DEV_PATH_TUN */
 			if (path->type == DEV_PATH_TUN) {
-- 
2.47.3

[PATCH net-next 5/9] net: do not advance stack index from dev_fwd_path()

[Pablo Neira Ayuso]

Update stack index from dev_fill_forward_path() instead, once the
forward path slot has been populated.

Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/core/dev.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index c1c1be1a6962..429a55fff667 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -742,12 +742,10 @@ EXPORT_SYMBOL_GPL(dev_fill_metadata_dst);
 
 static struct net_device_path *dev_fwd_path(struct net_device_path_stack *stack)
 {
-	int k = stack->num_paths++;
-
-	if (k >= NET_DEVICE_PATH_STACK_MAX)
+	if (stack->num_paths + 1 > NET_DEVICE_PATH_STACK_MAX)
 		return NULL;
 
-	return &stack->path[k];
+	return &stack->path[stack->num_paths];
 }
 
 int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr,
@@ -773,6 +771,7 @@ int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr,
 		if (ret < 0)
 			return -1;
 
+		stack->num_paths++;
 		if (WARN_ON_ONCE(last_dev == ctx.dev))
 			return -1;
 	}
@@ -785,6 +784,7 @@ int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr,
 		return -1;
 	path->type = DEV_PATH_ETHERNET;
 	path->dev = ctx.dev;
+	stack->num_paths++;
 
 	return ret;
 }
-- 
2.47.3

[PATCH net-next 6/9] net: pass dst via net_device_path in dev_fill_forward_path()

[Pablo Neira Ayuso]

Add dst_entry to tunnel device path, this will allow us to remove
a duplicated route lookup.

This is a preparation patch to retrieve the tunnel route directly
from the .fill_forward_path. This new dst_entry in the tunnel will be
used by a follow up patch.

Since dst_release() works fine on NULL interface, this is still
noop until the flowtable starts using this.

Add a new dev_fill_forward_path_release() function to drop the refcount
on the tunnel device route and use it in case of error out. Export it so
to drop the refcount on the tunnel route at a later stage.

Adjust existing drivers that recycle dev_fill_forward_path() to call
dev_fill_forward_path_release() for safety reasons.

Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 drivers/net/ethernet/airoha/airoha_ppe.c      | 10 ++++--
 .../net/ethernet/mediatek/mtk_ppe_offload.c   | 10 ++++--
 include/linux/netdevice.h                     |  2 ++
 net/core/dev.c                                | 36 ++++++++++++++++---
 4 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 33ddf0d07855..a03af9750573 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -296,14 +296,18 @@ static int airoha_ppe_get_wdma_info(struct net_device *dev, const u8 *addr,
 		return err;
 
 	path = &stack.path[stack.num_paths - 1];
-	if (path->type != DEV_PATH_MTK_WDMA)
-		return -EINVAL;
+	if (path->type != DEV_PATH_MTK_WDMA) {
+		err = -EINVAL;
+		goto err_out;
+	}
 
 	info->idx = path->mtk_wdma.wdma_idx;
 	info->bss = path->mtk_wdma.bss;
 	info->wcid = path->mtk_wdma.wcid;
+err_out:
+	dev_fill_forward_path_release(&stack);
 
-	return 0;
+	return err;
 }
 
 static int airoha_get_dsa_port(struct net_device **dev)
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
index cc8c4ef8038f..771d9118f94a 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
@@ -108,16 +108,20 @@ mtk_flow_get_wdma_info(struct net_device *dev, const u8 *addr, struct mtk_wdma_i
 		return err;
 
 	path = &stack.path[stack.num_paths - 1];
-	if (path->type != DEV_PATH_MTK_WDMA)
-		return -1;
+	if (path->type != DEV_PATH_MTK_WDMA) {
+		err = -EINVAL;
+		goto err_out;
+	}
 
 	info->wdma_idx = path->mtk_wdma.wdma_idx;
 	info->queue = path->mtk_wdma.queue;
 	info->bss = path->mtk_wdma.bss;
 	info->wcid = path->mtk_wdma.wcid;
 	info->amsdu = path->mtk_wdma.amsdu;
+err_out:
+	dev_fill_forward_path_release(&stack);
 
-	return 0;
+	return err;
 }
 
 
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8db25b79573e..62cfad7e6b79 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -892,6 +892,7 @@ struct net_device_path {
 			u8		h_dest[ETH_ALEN];
 		} encap;
 		struct {
+			struct dst_entry *dst;
 			union {
 				struct in_addr	src_v4;
 				struct in6_addr	src_v6;
@@ -3427,6 +3428,7 @@ int dev_get_iflink(const struct net_device *dev);
 int dev_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb);
 int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr,
 			  struct net_device_path_stack *stack);
+void dev_fill_forward_path_release(struct net_device_path_stack *stack);
 struct net_device *dev_get_by_name(struct net *net, const char *name);
 struct net_device *dev_get_by_name_rcu(struct net *net, const char *name);
 struct net_device *__dev_get_by_name(struct net *net, const char *name);
diff --git a/net/core/dev.c b/net/core/dev.c
index 429a55fff667..e50ed677de72 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -748,6 +748,27 @@ static struct net_device_path *dev_fwd_path(struct net_device_path_stack *stack)
 	return &stack->path[stack->num_paths];
 }
 
+void dev_fill_forward_path_release(struct net_device_path_stack *stack)
+{
+	struct net_device_path *path;
+	int k;
+
+	if (stack->num_paths == 0)
+		return;
+
+	for (k = stack->num_paths - 1; k >= 0; k--) {
+		path = &stack->path[k];
+		switch (path->type) {
+		case DEV_PATH_TUN:
+			dst_release(path->tun.dst);
+			break;
+		default:
+			break;
+		}
+	}
+}
+EXPORT_SYMBOL_GPL(dev_fill_forward_path_release);
+
 int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr,
 			  struct net_device_path_stack *stack)
 {
@@ -764,16 +785,16 @@ int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr,
 		last_dev = ctx.dev;
 		path = dev_fwd_path(stack);
 		if (!path)
-			return -1;
+			goto err_out;
 
 		memset(path, 0, sizeof(struct net_device_path));
 		ret = ctx.dev->netdev_ops->ndo_fill_forward_path(&ctx, path);
 		if (ret < 0)
-			return -1;
+			goto err_out;
 
 		stack->num_paths++;
 		if (WARN_ON_ONCE(last_dev == ctx.dev))
-			return -1;
+			goto err_out;
 	}
 
 	if (!ctx.dev)
@@ -781,12 +802,17 @@ int dev_fill_forward_path(const struct net_device *dev, const u8 *daddr,
 
 	path = dev_fwd_path(stack);
 	if (!path)
-		return -1;
+		goto err_out;
+
 	path->type = DEV_PATH_ETHERNET;
 	path->dev = ctx.dev;
 	stack->num_paths++;
 
-	return ret;
+	return 0;
+err_out:
+	dev_fill_forward_path_release(stack);
+
+	return -1;
 }
 EXPORT_SYMBOL_GPL(dev_fill_forward_path);
 
-- 
2.47.3

[PATCH net-next 7/9] netfilter: flowtable: release tunnel route on error when building forward path

[Pablo Neira Ayuso]

nft_flow_tunnel_update_route() can lazy fail, leaving an incomplete
forward path set ip. The route lookup also happens twice, once from
dev_fill_forward_path() and again in this aforementioned function.

Update ipip and ip6ip6 not to release the dst_entry and pass it on
via the tunnel forward path information.

In case of failure when setting up the forwarding path, release the
tunnel dst that was provided via dev_fill_forward_path().

Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/ipv4/ipip.c                    |  2 +-
 net/ipv6/ip6_tunnel.c              |  4 +-
 net/netfilter/nf_flow_table_path.c | 65 ++++++++----------------------
 3 files changed, 21 insertions(+), 50 deletions(-)

diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 0831f6b81717..fb7d96f99b06 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -376,10 +376,10 @@ static int ipip_fill_forward_path(struct net_device_path_ctx *ctx,
 	path->tun.src_v4.s_addr = tiph->saddr;
 	path->tun.dst_v4.s_addr = tiph->daddr;
 	path->tun.l3_proto = IPPROTO_IPIP;
+	path->tun.dst = &rt->dst;
 	path->dev = ctx->dev;
 
 	ctx->dev = rt->dst.dev;
-	ip_rt_put(rt);
 
 	return 0;
 }
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 97c3f61d627b..d80020bc2620 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1870,12 +1870,14 @@ static int ip6_tnl_fill_forward_path(struct net_device_path_ctx *ctx,
 		path->tun.src_v6 = fl6.saddr;
 		path->tun.dst_v6 = fl6.daddr;
 		path->tun.l3_proto = IPPROTO_IPV6;
+		path->tun.dst = dst;
 		path->dev = ctx->dev;
 		ctx->dev = dst->dev;
 	}
 
 	err = dst->error;
-	dst_release(dst);
+	if (err)
+		dst_release(dst);
 
 	return err;
 }
diff --git a/net/netfilter/nf_flow_table_path.c b/net/netfilter/nf_flow_table_path.c
index 004dc75ac357..56219b02e122 100644
--- a/net/netfilter/nf_flow_table_path.c
+++ b/net/netfilter/nf_flow_table_path.c
@@ -82,6 +82,7 @@ struct nft_forward_info {
 	} encap[NF_FLOW_TABLE_ENCAP_MAX];
 	u8 num_encaps;
 	struct flow_offload_tunnel tun;
+	struct dst_entry *tun_dst;
 	u8 num_tuns;
 	u8 ingress_vlans;
 	u8 h_source[ETH_ALEN];
@@ -93,7 +94,7 @@ struct nft_forward_info {
 static bool nft_flowtable_find_dev(const struct net_device *dev,
 				   struct nft_flowtable *ft);
 
-static int nft_dev_path_info(const struct net_device_path_stack *stack,
+static int nft_dev_path_info(struct net_device_path_stack *stack,
 			     struct nft_forward_info *info,
 			     unsigned char *ha, struct nft_flowtable *ft)
 {
@@ -121,15 +122,16 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 			/* DEV_PATH_VLAN, DEV_PATH_PPPOE and DEV_PATH_TUN */
 			if (path->type == DEV_PATH_TUN) {
 				if (info->num_tuns)
-					return -1;
+					goto err_out;
 
 				info->tun.src_v6 = path->tun.src_v6;
 				info->tun.dst_v6 = path->tun.dst_v6;
 				info->tun.l3_proto = path->tun.l3_proto;
+				info->tun_dst = path->tun.dst;
 				info->num_tuns++;
 			} else {
 				if (info->num_encaps >= NF_FLOW_TABLE_ENCAP_MAX)
-					return -1;
+					goto err_out;
 
 				info->encap[info->num_encaps].id =
 					path->encap.id;
@@ -150,13 +152,13 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 			switch (path->bridge.vlan_mode) {
 			case DEV_PATH_BR_VLAN_UNTAG_HW:
 				if (info->num_encaps == 0)
-					return -1;
+					goto err_out;
 
 				info->ingress_vlans |= BIT(info->num_encaps - 1);
 				break;
 			case DEV_PATH_BR_VLAN_TAG:
 				if (info->num_encaps >= NF_FLOW_TABLE_ENCAP_MAX)
-					return -1;
+					goto err_out;
 
 				info->encap[info->num_encaps].id = path->bridge.vlan_id;
 				info->encap[info->num_encaps].proto = path->bridge.vlan_proto;
@@ -164,7 +166,7 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 				break;
 			case DEV_PATH_BR_VLAN_UNTAG:
 				if (info->num_encaps == 0)
-					return -1;
+					goto err_out;
 
 				info->num_encaps--;
 				break;
@@ -174,7 +176,7 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 			info->xmit_type = FLOW_OFFLOAD_XMIT_DIRECT;
 			break;
 		default:
-			return -1;
+			goto err_out;
 		}
 	}
 
@@ -183,9 +185,13 @@ static int nft_dev_path_info(const struct net_device_path_stack *stack,
 		info->xmit_type = FLOW_OFFLOAD_XMIT_DIRECT;
 
 	if (!nft_flowtable_find_dev(info->dev, ft))
-		return -1;
+		goto err_out;
 
 	return 0;
+err_out:
+	dev_fill_forward_path_release(stack);
+
+	return -1;
 }
 
 static bool nft_flowtable_find_dev(const struct net_device *dev,
@@ -205,44 +211,6 @@ static bool nft_flowtable_find_dev(const struct net_device *dev,
 	return found;
 }
 
-static int nft_flow_tunnel_update_route(const struct nft_pktinfo *pkt,
-					struct flow_offload_tunnel *tun,
-					struct nf_flow_route *route,
-					enum ip_conntrack_dir dir)
-{
-	struct dst_entry *cur_dst = route->tuple[dir].dst;
-	struct dst_entry *tun_dst = NULL;
-	struct flowi fl = {};
-
-	switch (nft_pf(pkt)) {
-	case NFPROTO_IPV4:
-		fl.u.ip4.daddr = tun->dst_v4.s_addr;
-		fl.u.ip4.saddr = tun->src_v4.s_addr;
-		fl.u.ip4.flowi4_iif = nft_in(pkt)->ifindex;
-		fl.u.ip4.flowi4_dscp = ip4h_dscp(ip_hdr(pkt->skb));
-		fl.u.ip4.flowi4_mark = pkt->skb->mark;
-		fl.u.ip4.flowi4_flags = FLOWI_FLAG_ANYSRC;
-		break;
-	case NFPROTO_IPV6:
-		fl.u.ip6.daddr = tun->dst_v6;
-		fl.u.ip6.saddr = tun->src_v6;
-		fl.u.ip6.flowi6_iif = nft_in(pkt)->ifindex;
-		fl.u.ip6.flowlabel = ip6_flowinfo(ipv6_hdr(pkt->skb));
-		fl.u.ip6.flowi6_mark = pkt->skb->mark;
-		fl.u.ip6.flowi6_flags = FLOWI_FLAG_ANYSRC;
-		break;
-	}
-
-	nf_route(nft_net(pkt), &tun_dst, &fl, false, nft_pf(pkt));
-	if (!tun_dst)
-		return -ENOENT;
-
-	route->tuple[dir].dst = tun_dst;
-	dst_release(cur_dst);
-
-	return 0;
-}
-
 static int nft_dev_forward_path(const struct nft_pktinfo *pkt,
 				struct nf_flow_route *route,
 				const struct nf_conn *ct,
@@ -267,12 +235,13 @@ static int nft_dev_forward_path(const struct nft_pktinfo *pkt,
 		route->tuple[!dir].in.encap[i].proto = info.encap[i].proto;
 	}
 
-	if (info.num_tuns &&
-	    !nft_flow_tunnel_update_route(pkt, &info.tun, route, dir)) {
+	if (info.num_tuns) {
 		route->tuple[!dir].in.tun.src_v6 = info.tun.dst_v6;
 		route->tuple[!dir].in.tun.dst_v6 = info.tun.src_v6;
 		route->tuple[!dir].in.tun.l3_proto = info.tun.l3_proto;
 		route->tuple[!dir].in.num_tuns = info.num_tuns;
+		dst_release(route->tuple[dir].dst);
+		route->tuple[dir].dst = info.tun_dst;
 	}
 
 	route->tuple[!dir].in.num_encaps = info.num_encaps;
-- 
2.47.3

[PATCH net-next 8/9] netfilter: nf_tables: call skb_valid_dst() before skb_dst()

[Pablo Neira Ayuso]

When fetching the dst_entry from the skb, check if it valid, ie. this is
not a template dst, for extensions that can be used from the netdev
ingress and egress chains.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/ipv4/netfilter/nf_reject_ipv4.c | 6 ++++--
 net/ipv6/netfilter/nf_reject_ipv6.c | 8 ++++++--
 net/netfilter/nft_meta.c            | 6 ++++--
 net/netfilter/nft_rt.c              | 6 ++++--
 net/netfilter/nft_xfrm.c            | 9 ++++++++-
 5 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/net/ipv4/netfilter/nf_reject_ipv4.c b/net/ipv4/netfilter/nf_reject_ipv4.c
index 4626dc46808f..59ec465a9df9 100644
--- a/net/ipv4/netfilter/nf_reject_ipv4.c
+++ b/net/ipv4/netfilter/nf_reject_ipv4.c
@@ -8,6 +8,7 @@
 #include <net/tcp.h>
 #include <net/route.h>
 #include <net/dst.h>
+#include <net/dst_metadata.h>
 #include <net/netfilter/ipv4/nf_reject.h>
 #include <linux/netfilter_ipv4.h>
 #include <linux/netfilter_bridge.h>
@@ -263,6 +264,7 @@ static int nf_reject_fill_skb_dst(struct sk_buff *skb_in)
 	if (!dst)
 		return -1;
 
+	skb_dst_drop(skb_in);
 	skb_dst_set(skb_in, dst);
 	return 0;
 }
@@ -279,7 +281,7 @@ void nf_send_reset(struct net *net, struct sock *sk, struct sk_buff *oldskb,
 	if (!oth)
 		return;
 
-	if (!skb_dst(oldskb) && nf_reject_fill_skb_dst(oldskb) < 0)
+	if (!skb_valid_dst(oldskb) && nf_reject_fill_skb_dst(oldskb) < 0)
 		return;
 
 	if (skb_rtable(oldskb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
@@ -352,7 +354,7 @@ void nf_send_unreach(struct sk_buff *skb_in, int code, int hook)
 	if (iph->frag_off & htons(IP_OFFSET))
 		return;
 
-	if (!skb_dst(skb_in) && nf_reject_fill_skb_dst(skb_in) < 0)
+	if (!skb_valid_dst(skb_in) && nf_reject_fill_skb_dst(skb_in) < 0)
 		return;
 
 	if (skb_csum_unnecessary(skb_in) ||
diff --git a/net/ipv6/netfilter/nf_reject_ipv6.c b/net/ipv6/netfilter/nf_reject_ipv6.c
index ef5b7e85cffa..07cdaa10da0d 100644
--- a/net/ipv6/netfilter/nf_reject_ipv6.c
+++ b/net/ipv6/netfilter/nf_reject_ipv6.c
@@ -8,6 +8,7 @@
 #include <net/ip6_route.h>
 #include <net/ip6_fib.h>
 #include <net/ip6_checksum.h>
+#include <net/dst_metadata.h>
 #include <net/netfilter/ipv6/nf_reject.h>
 #include <linux/netfilter_ipv6.h>
 #include <linux/netfilter_bridge.h>
@@ -304,6 +305,7 @@ static int nf_reject6_fill_skb_dst(struct sk_buff *skb_in)
 	if (!dst)
 		return -1;
 
+	skb_dst_drop(skb_in);
 	skb_dst_set(skb_in, dst);
 	return 0;
 }
@@ -336,10 +338,12 @@ void nf_send_reset6(struct net *net, struct sock *sk, struct sk_buff *oldskb,
 	fl6.fl6_sport = otcph->dest;
 	fl6.fl6_dport = otcph->source;
 
-	if (!skb_dst(oldskb)) {
+	if (!skb_valid_dst(oldskb)) {
 		nf_ip6_route(net, &dst, flowi6_to_flowi(&fl6), false);
 		if (!dst)
 			return;
+
+		skb_dst_drop(oldskb);
 		skb_dst_set(oldskb, dst);
 	}
 
@@ -440,7 +444,7 @@ void nf_send_unreach6(struct net *net, struct sk_buff *skb_in,
 	if (hooknum == NF_INET_LOCAL_OUT && skb_in->dev == NULL)
 		skb_in->dev = net->loopback_dev;
 
-	if (!skb_dst(skb_in) && nf_reject6_fill_skb_dst(skb_in) < 0)
+	if (!skb_valid_dst(skb_in) && nf_reject6_fill_skb_dst(skb_in) < 0)
 		return;
 
 	icmpv6_send(skb_in, ICMPV6_DEST_UNREACH, code, 0);
diff --git a/net/netfilter/nft_meta.c b/net/netfilter/nft_meta.c
index 0a43e0787a68..01cfbaa36525 100644
--- a/net/netfilter/nft_meta.c
+++ b/net/netfilter/nft_meta.c
@@ -20,6 +20,7 @@
 #include <net/dst.h>
 #include <net/ip.h>
 #include <net/sock.h>
+#include <net/dst_metadata.h>
 #include <net/tcp_states.h> /* for TCP_TIME_WAIT */
 #include <net/netfilter/nf_tables.h>
 #include <net/netfilter/nf_tables_core.h>
@@ -279,11 +280,12 @@ static bool nft_meta_get_eval_ifname(enum nft_meta_keys key, u32 *dest,
 static noinline bool
 nft_meta_get_eval_rtclassid(const struct sk_buff *skb, u32 *dest)
 {
-	const struct dst_entry *dst = skb_dst(skb);
+	const struct dst_entry *dst;
 
-	if (!dst)
+	if (!skb_valid_dst(skb))
 		return false;
 
+	dst = skb_dst(skb);
 	*dest = dst->tclassid;
 	return true;
 }
diff --git a/net/netfilter/nft_rt.c b/net/netfilter/nft_rt.c
index aeb0094eafd8..841c863a08db 100644
--- a/net/netfilter/nft_rt.c
+++ b/net/netfilter/nft_rt.c
@@ -8,6 +8,7 @@
 #include <linux/netfilter.h>
 #include <linux/netfilter/nf_tables.h>
 #include <net/dst.h>
+#include <net/dst_metadata.h>
 #include <net/ip6_route.h>
 #include <net/route.h>
 #include <net/netfilter/nf_tables.h>
@@ -59,10 +60,11 @@ void nft_rt_get_eval(const struct nft_expr *expr,
 	u32 *dest = &regs->data[priv->dreg];
 	const struct dst_entry *dst;
 
-	dst = skb_dst(skb);
-	if (!dst)
+	if (!skb_valid_dst(skb))
 		goto err;
 
+	dst = skb_dst(skb);
+
 	switch (priv->key) {
 #ifdef CONFIG_IP_ROUTE_CLASSID
 	case NFT_RT_CLASSID:
diff --git a/net/netfilter/nft_xfrm.c b/net/netfilter/nft_xfrm.c
index 8cec43064319..c8bba697f993 100644
--- a/net/netfilter/nft_xfrm.c
+++ b/net/netfilter/nft_xfrm.c
@@ -12,6 +12,7 @@
 #include <linux/netfilter/nf_tables.h>
 #include <net/netfilter/nf_tables_core.h>
 #include <net/netfilter/nf_tables.h>
+#include <net/dst_metadata.h>
 #include <linux/in.h>
 #include <net/xfrm.h>
 
@@ -177,9 +178,15 @@ static void nft_xfrm_get_eval_out(const struct nft_xfrm *priv,
 				  struct nft_regs *regs,
 				  const struct nft_pktinfo *pkt)
 {
-	const struct dst_entry *dst = skb_dst(pkt->skb);
+	const struct dst_entry *dst;
 	int i;
 
+	if (!skb_valid_dst(pkt->skb)) {
+		regs->verdict.code = NFT_BREAK;
+		return;
+	}
+
+	dst = skb_dst(pkt->skb);
 	for (i = 0; dst && dst->xfrm;
 	     dst = ((const struct xfrm_dst *)dst)->child, i++) {
 		if (i < priv->spnum)
-- 
2.47.3

[PATCH net-next 9/9] netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets

[Pablo Neira Ayuso]

From: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>

Commit be0502a3f2e9 ("netfilter: conntrack: tcp: only close if RST
matches exact sequence") keeps an established conntrack entry in
ESTABLISHED when an in-window RST does not match the expected sequence
number exactly, so the endpoint can validate the RST with a challenge
ACK.

The timeout selection nevertheless uses the CLOSE timeout for every RST
packet.  The bug is that timeout selection is based on the packet type,
not on the state transition result: even when RST validation keeps
new_state in ESTABLISHED, the timeout is still forced to
TCP_CONNTRACK_CLOSE.

Linux TCP independently rate limits challenge ACKs per socket.  A second
non-exact RST can therefore arrive after the first challenge ACK has
restored the timeout but before the rate limit expires.  The second RST
lowers the timeout to 10 seconds again while the endpoint suppresses the
second challenge ACK, allowing the conntrack entry to expire while both
TCP endpoints remain established.

Using the ESTABLISHED timeout for such RSTs would avoid this short
expiration window, but it could also retain stale entries for the
five-day default because conntrack cannot reliably match the endpoint's
exact TCP state.

Use the UNACK timeout for RST packets that leave the conntrack entry in
TCP_CONNTRACK_ESTABLISHED.  Exact-match RSTs and accepted RST packet
trains still fall through to timeouts[new_state], which preserves the
CLOSE timeout when conntrack accepts the RST as closing the flow.

This avoids the aggressive 10-second expiration window for non-exact
RSTs while preserving the short timeout for RSTs that conntrack accepts
as closing the flow.

Suggested-by: Florian Westphal <fw@strlen.de>
Reported-by: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>
Reported-by: Jianjun Chen <jianjun@tsinghua.edu.cn>
Signed-off-by: Minghao Zhang <zhangmh25@mails.tsinghua.edu.cn>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nf_conntrack_proto_tcp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index ceeed3d7fe52..723e946a78f4 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -1281,8 +1281,9 @@ int nf_conntrack_tcp_packet(struct nf_conn *ct,
 	if (ct->proto.tcp.retrans >= tn->tcp_max_retrans &&
 	    timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
 		timeout = timeouts[TCP_CONNTRACK_RETRANS];
-	else if (unlikely(index == TCP_RST_SET))
-		timeout = timeouts[TCP_CONNTRACK_CLOSE];
+	else if (unlikely(index == TCP_RST_SET &&
+			  new_state == TCP_CONNTRACK_ESTABLISHED))
+		timeout = timeouts[TCP_CONNTRACK_UNACK];
 	else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
 		 IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
 		 timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
-- 
2.47.3

Re: [PATCH net-next 7/9] netfilter: flowtable: release tunnel route on error when building forward path

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
netfilter: flowtable: release tunnel route on error when building forward path

This drops the second route lookup in nft_flow_tunnel_update_route() and
instead passes the dst_entry obtained by dev_fill_forward_path() through
the tunnel forward path information, so ipip and ip6ip6 no longer release
it.  On failure while building the forward path the tunnel dst is released
via dev_fill_forward_path_release().

> diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
> index 0831f6b81717c..fb7d96f99b06b 100644
> --- a/net/ipv4/ipip.c
> +++ b/net/ipv4/ipip.c
> @@ -376,10 +376,10 @@ static int ipip_fill_forward_path(struct net_device_path_ctx *ctx,
>  	path->tun.src_v4.s_addr = tiph->saddr;
>  	path->tun.dst_v4.s_addr = tiph->daddr;
>  	path->tun.l3_proto = IPPROTO_IPIP;
> +	path->tun.dst = &rt->dst;
>  	path->dev = ctx->dev;
>  
>  	ctx->dev = rt->dst.dev;
> -	ip_rt_put(rt);
>  
>  	return 0;
>  }
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 97c3f61d627bb..d80020bc2620e 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1870,12 +1870,14 @@ static int ip6_tnl_fill_forward_path(struct net_device_path_ctx *ctx,
>  		path->tun.src_v6 = fl6.saddr;
>  		path->tun.dst_v6 = fl6.daddr;
>  		path->tun.l3_proto = IPPROTO_IPV6;
> +		path->tun.dst = dst;
>  		path->dev = ctx->dev;
>  		ctx->dev = dst->dev;
>  	}
>  
>  	err = dst->error;
> -	dst_release(dst);
> +	if (err)
> +		dst_release(dst);
>  
>  	return err;
>  }
> diff --git a/net/netfilter/nf_flow_table_path.c b/net/netfilter/nf_flow_table_path.c
> index 004dc75ac357a..56219b02e1227 100644
> --- a/net/netfilter/nf_flow_table_path.c
> +++ b/net/netfilter/nf_flow_table_path.c

[ ... ]

> @@ -205,44 +211,6 @@ static bool nft_flowtable_find_dev(const struct net_device *dev,
>  	return found;
>  }
>  
> -static int nft_flow_tunnel_update_route(const struct nft_pktinfo *pkt,
> -					struct flow_offload_tunnel *tun,
> -					struct nf_flow_route *route,
> -					enum ip_conntrack_dir dir)
> -{
> -	struct dst_entry *cur_dst = route->tuple[dir].dst;
> -	struct dst_entry *tun_dst = NULL;
> -	struct flowi fl = {};
> -
> -	switch (nft_pf(pkt)) {

[ ... ]

> -	nf_route(nft_net(pkt), &tun_dst, &fl, false, nft_pf(pkt));
> -	if (!tun_dst)
> -		return -ENOENT;
> -
> -	route->tuple[dir].dst = tun_dst;
> -	dst_release(cur_dst);
> -
> -	return 0;
> -}
> -
>  static int nft_dev_forward_path(const struct nft_pktinfo *pkt,
>  				struct nf_flow_route *route,
>  				const struct nf_conn *ct,
> @@ -267,12 +235,13 @@ static int nft_dev_forward_path(const struct nft_pktinfo *pkt,
>  		route->tuple[!dir].in.encap[i].proto = info.encap[i].proto;
>  	}
>  
> -	if (info.num_tuns &&
> -	    !nft_flow_tunnel_update_route(pkt, &info.tun, route, dir)) {
> +	if (info.num_tuns) {
>  		route->tuple[!dir].in.tun.src_v6 = info.tun.dst_v6;
>  		route->tuple[!dir].in.tun.dst_v6 = info.tun.src_v6;
>  		route->tuple[!dir].in.tun.l3_proto = info.tun.l3_proto;
>  		route->tuple[!dir].in.num_tuns = info.num_tuns;
> +		dst_release(route->tuple[dir].dst);
> +		route->tuple[dir].dst = info.tun_dst;
>  	}

[Severity: High]
Can the dst installed here end up belonging to a different address family
than the flow it is attached to?

The removed nft_flow_tunnel_update_route() derived the replacement dst from
nf_route(nft_net(pkt), &tun_dst, &fl, false, nft_pf(pkt)), so the dst family
always matched the flow's l3proto.  The dst that now arrives in
info.tun_dst follows the tunnel underlay instead:

net/ipv4/ipip.c:ipip_fill_forward_path() always stores an IPv4 rtable:

	path->tun.l3_proto = IPPROTO_IPIP;
	path->tun.dst = &rt->dst;

net/ipv6/ip6_tunnel.c:ip6_tnl_fill_forward_path() always stores an IPv6
rt6_info:

	path->tun.l3_proto = IPPROTO_IPV6;
	path->tun.dst = dst;

Neither handler consults the tunnel payload proto, and neither
nft_dev_path_info() nor nft_dev_forward_path() checks the family before
storing it in route->tuple[dir].dst.

The consumers cast that dst according to the inner flow family.  In
net/netfilter/nf_flow_table_ip.c:nf_flow_offload_ipv6_hook():

	rt = dst_rt6_info(tuplehash->tuple.dst_cache);
	...
	neigh = ip_neigh_gw6(rt->dst.dev, rt6_nexthop(rt, ip6_daddr));

and in nf_flow_offload_ip_hook():

	rt = dst_rtable(tuplehash->tuple.dst_cache);
	... rt_nexthop(rt, ip_daddr) ...

net/netfilter/nf_flow_table_core.c:flow_offload_dst_cookie() does the same:

	if (flow_tuple->l3proto == NFPROTO_IPV6)
		return rt6_get_cookie(dst_rt6_info(flow_tuple->dst_cache));

For an ip6_tunnel in ip4ip6 mode (t->parms.proto == IPPROTO_IPIP) carrying
IPv4 flows, ip6_tnl_fill_forward_path() still reports l3_proto =
IPPROTO_IPV6 and hands out an rt6_info, which nf_flow_offload_ip_hook()
then reads through dst_rtable() and rt_nexthop()/ip_mtu_locked().  That
configuration needs no misconfiguration to reach.

The mirror case is an IPv6 flow routed out an ipip device: an ipip device
with mtu 1480 gets an inet6_dev at NETDEV_REGISTER, so fib6_nh_init()
accepts "ip -6 route add ... dev tunlX", and nft_dev_fill_forward_path()
deliberately skips the ether-device requirement for tunnels, so
ipip_fill_forward_path() hands back an rtable that becomes the dst_cache of
an IPv6 flow.  rt6_nexthop() then reads rt6i_flags and rt6i_gateway past
the end of a struct rtable allocated from the ip_dst_cache slab, and the
result is used as the IPv6 next hop passed to ip_neigh_gw6().

nf_flow_dst_check() does not catch this either: dst->ops->check() for the
stored rtable is ipv4_dst_check(), which only tests rt_is_expired().

Would it make sense to validate info.tun.l3_proto (or the dst's
ops->family) against the flow's l3proto before installing info.tun_dst?

[Severity: Low]
Should this carry a Fixes: tag?

Before this change the tunnel information was only installed when the
second lookup succeeded:

	if (info.num_tuns &&
	    !nft_flow_tunnel_update_route(pkt, &info.tun, route, dir)) {

while route->tuple[!dir].in.ifindex, route->tuple[dir].out.ifindex, the
encaps, h_source/h_dest and xmit_type had already been written and
nft_dev_forward_path() still returned 0.  On nf_route() failure the flow was
offloaded with the underlay device as output but num_tuns == 0, so inner
packets left the underlay without IPIP/IP6IP6 encapsulation, which matches
the "incomplete forward path" described in the commit message.

git blame points that construct at d30301ba4b07ac ("netfilter: flowtable:
tunnel route update"), with the tunnel forward path support itself from
ab427db1788581, so the bug is in released kernels rather than in-flight
code from this series.  A Fixes: d30301ba4b07ac tag would help stable
tracking.

It may also be worth noting in the changelog that this is not standalone
backportable: neither dev_fill_forward_path_release() nor the
net_device_path tun.dst field exist before the earlier "net: pass dst via
net_device_path in dev_fill_forward_path()" commit in this series.

Re: [PATCH net-next 9/9] netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets

This changes the timeout selection in nf_conntrack_tcp_packet() so that an
RST which leaves the entry in TCP_CONNTRACK_ESTABLISHED (the non-exact
sequence case from be0502a3f2e9) gets timeouts[TCP_CONNTRACK_UNACK] instead
of timeouts[TCP_CONNTRACK_CLOSE].  RSTs that conntrack accepts as closing
the flow are meant to keep using timeouts[new_state].

A few questions below.

>     Use the UNACK timeout for RST packets that leave the conntrack entry in
>     TCP_CONNTRACK_ESTABLISHED.  Exact-match RSTs and accepted RST packet
>     trains still fall through to timeouts[new_state], which preserves the
>     CLOSE timeout when conntrack accepts the RST as closing the flow.

[Severity: Low]
Should this carry a Fixes: tag?  The changelog describes a user-visible
failure (an ESTABLISHED entry expiring after 10 seconds while both TCP
endpoints stay established), and it names be0502a3f2e9 in prose only, so
stable tooling has nothing machine-readable to key on.

There is also a wording tension: be0502a3f2e9's own changelog presented the
CLOSE timeout for non-exact RSTs as intentional ("With patch, timeout is
lowered like CLOSE, but connection stays in ESTABLISHED state" / "If no
challenge ACK is received, the connection will time out after CLOSE
seconds").  Either adding

    Fixes: be0502a3f2e94211 ("netfilter: conntrack: tcp: only close if RST matches exact sequence")

or rewording this as a deliberate policy refinement rather than a bug fix
would make the two consistent.

[Severity: Low]
Is there a test that observes this change?  The only in-tree artifact
covering the inexact in-window RST path,
tools/testing/selftests/net/netfilter/packetdrill/conntrack_rst_invalid.pkt,
checks only the state string:

    // in-window but not exact match
    +0.0 < R	42:42(0)	win 0
    +0 `conntrack -f $NFCT_IP_VERSION -L -p tcp --dport 8080 2>/dev/null |grep -q ESTABLISHED`

The timeout is now the sole observable difference for that scenario, and it
is never inspected.

On top of that, the segment labelled "in-window but not exact match" has seq
before seen[!dir].td_maxack (the peer had acked 3001), so
nf_conntrack_tcp_packet() rejects it at the "invalid rst" check and never
reaches the patched timeout selection.  The test's own counter assertion
agrees:

    // Expect four invalid RSTs
    +0 `$xtables -v -S INPUT  | grep INVALID | grep -q -- "-c 4 "`

So the suite passes identically with and without this change.

> diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
> index ceeed3d7fe520..723e946a78f40 100644
> --- a/net/netfilter/nf_conntrack_proto_tcp.c
> +++ b/net/netfilter/nf_conntrack_proto_tcp.c
> @@ -1281,8 +1281,9 @@ int nf_conntrack_tcp_packet(struct nf_conn *ct,
>  	if (ct->proto.tcp.retrans >= tn->tcp_max_retrans &&
>  	    timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
>  		timeout = timeouts[TCP_CONNTRACK_RETRANS];
> -	else if (unlikely(index == TCP_RST_SET))
> -		timeout = timeouts[TCP_CONNTRACK_CLOSE];
> +	else if (unlikely(index == TCP_RST_SET &&
> +			  new_state == TCP_CONNTRACK_ESTABLISHED))
> +		timeout = timeouts[TCP_CONNTRACK_UNACK];

[Severity: Medium]
Can this new branch lengthen an entry's lifetime rather than shorten it?
Every sibling branch in this chain only assigns when the replacement is
smaller, for example the RETRANS branch just above and the UNACK branch just
below:

    if (ct->proto.tcp.retrans >= tn->tcp_max_retrans &&
        timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
        timeout = timeouts[TCP_CONNTRACK_RETRANS];
    ...
    else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
         IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
         timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
        timeout = timeouts[TCP_CONNTRACK_UNACK];

The new branch has no such guard.  Since this branch is only reachable via
"new_state = old_state;" in case TCP_CONNTRACK_CLOSE, new_state is
ESTABLISHED here, so the effective comparison is timeouts[UNACK] against
timeouts[ESTABLISHED].

With the defaults in tcp_timeouts (ESTABLISHED 5 DAYS, UNACK 5 MINS) this is
always a lowering.  But both values are independently tunable with no
cross-validation:

    net/netfilter/nf_conntrack_standalone.c:
    [NF_SYSCTL_CT_PROTO_TIMEOUT_TCP_ESTABLISHED] = {
        .procname	= "nf_conntrack_tcp_timeout_established",
        .maxlen		= sizeof(unsigned int),
        .mode		= 0644,
        .proc_handler	= proc_dointvec_jiffies,
    },

and tcp_timeout_nlattr_to_obj() copies CTA_TIMEOUT_TCP_* verbatim.  So an
administrator lowering nf_conntrack_tcp_timeout_established (120 s is a
common hardening/NAT-appliance setting) inverts the relation.

__nf_ct_refresh_acct() then writes the expiry absolutely rather than
clamping it:

    net/netfilter/nf_conntrack_core.c:__nf_ct_refresh_acct() {
        ...
        if (nf_ct_is_confirmed(ct))
            extra_jiffies += nfct_time_stamp;

        if (READ_ONCE(ct->timeout) != extra_jiffies)
            WRITE_ONCE(ct->timeout, extra_jiffies);
        ...
    }

In that configuration, an in-window RST whose sequence does not match
td_maxack pushes the entry past the configured ESTABLISHED policy, and a
periodic stream of such RSTs can renew it indefinitely, holding entries
against nf_conntrack_max.  Would the usual form keep the intent while
avoiding this?

    timeout = min(timeouts[new_state], timeouts[TCP_CONNTRACK_UNACK]);

or the matching guard:

    else if (unlikely(index == TCP_RST_SET &&
                      new_state == TCP_CONNTRACK_ESTABLISHED) &&
             timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])

>  	else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
>  		 IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
>  		 timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])

[Severity: Low]
For an RST that conntrack does accept as closing the flow, is the CLOSE
timeout really preserved?  Previously such packets took the unconditional
timeouts[TCP_CONNTRACK_CLOSE] assignment; now they fall through into the
DATA_UNACKNOWLEDGED and last_win == 0 branches:

    else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
         IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
         timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
        timeout = timeouts[TCP_CONNTRACK_UNACK];
    else if (ct->proto.tcp.last_win == 0 &&
         timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
        timeout = timeouts[TCP_CONNTRACK_RETRANS];

Those fire precisely when nf_conntrack_tcp_timeout_close is raised above
nf_conntrack_tcp_timeout_unacknowledged or the retrans timeout, and both
preconditions are reachable for a closing RST: IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED
is commonly set on a flow that carried data, and ct->proto.tcp.last_win is
sticky since it is only refreshed for ACK-only segments.

This also diverges from the other closing path in the same file, which does
not cap:

    nf_conntrack_tcp_set_closing() {
        ...
        timeout = timeouts[TCP_CONNTRACK_CLOSE];
        WRITE_ONCE(ct->timeout, timeout + nfct_time_stamp);
        ...
    }

Given that, is the changelog sentence "Exact-match RSTs and accepted RST
packet trains still fall through to timeouts[new_state], which preserves the
CLOSE timeout when conntrack accepts the RST as closing the flow" accurate
for non-default close timeouts?  Restoring an explicit CLOSE assignment for
new_state == TCP_CONNTRACK_CLOSE, or adjusting the wording, would resolve
it.

Re: [PATCH net-next 9/9] netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets

[Pablo Neira Ayuso]

On Tue, Aug 04, 2026 at 05:19:07PM -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
> 
> This changes the timeout selection in nf_conntrack_tcp_packet() so that an
> RST which leaves the entry in TCP_CONNTRACK_ESTABLISHED (the non-exact
> sequence case from be0502a3f2e9) gets timeouts[TCP_CONNTRACK_UNACK] instead
> of timeouts[TCP_CONNTRACK_CLOSE].  RSTs that conntrack accepts as closing
> the flow are meant to keep using timeouts[new_state].
> 
> A few questions below.
> 
> >     Use the UNACK timeout for RST packets that leave the conntrack entry in
> >     TCP_CONNTRACK_ESTABLISHED.  Exact-match RSTs and accepted RST packet
> >     trains still fall through to timeouts[new_state], which preserves the
> >     CLOSE timeout when conntrack accepts the RST as closing the flow.
> 
> [Severity: Low]
> Should this carry a Fixes: tag?
 
No, and it is intentional.

We do not want updates on the conntrack state machine to automatically
end up in -stable.

Do we have to write this in the cover letter from this time on?

> [...] The changelog describes a user-visible
> failure (an ESTABLISHED entry expiring after 10 seconds while both TCP
> endpoints stay established), and it names be0502a3f2e9 in prose only, so
> stable tooling has nothing machine-readable to key on.
>
> There is also a wording tension: be0502a3f2e9's own changelog presented the
> CLOSE timeout for non-exact RSTs as intentional ("With patch, timeout is
> lowered like CLOSE, but connection stays in ESTABLISHED state" / "If no
> challenge ACK is received, the connection will time out after CLOSE
> seconds").  Either adding
> 
>     Fixes: be0502a3f2e94211 ("netfilter: conntrack: tcp: only close if RST matches exact sequence")
> 
> or rewording this as a deliberate policy refinement rather than a bug fix
> would make the two consistent.
> 
> [Severity: Low]
> Is there a test that observes this change?

No, it is just a timeout update in conntrack, there is nothing the
packetdrill test can do about this.

> The only in-tree artifact covering the inexact in-window RST path,
> tools/testing/selftests/net/netfilter/packetdrill/conntrack_rst_invalid.pkt,
> checks only the state string:
> 
>     // in-window but not exact match
>     +0.0 < R	42:42(0)	win 0
>     +0 `conntrack -f $NFCT_IP_VERSION -L -p tcp --dport 8080 2>/dev/null |grep -q ESTABLISHED`
> 
> The timeout is now the sole observable difference for that scenario, and it
> is never inspected.
> 
> On top of that, the segment labelled "in-window but not exact match" has seq
> before seen[!dir].td_maxack (the peer had acked 3001), so
> nf_conntrack_tcp_packet() rejects it at the "invalid rst" check and never
> reaches the patched timeout selection.  The test's own counter assertion
> agrees:
> 
>     // Expect four invalid RSTs
>     +0 `$xtables -v -S INPUT  | grep INVALID | grep -q -- "-c 4 "`
> 
> So the suite passes identically with and without this change.

Yes, that is expected.

> > diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
> > index ceeed3d7fe520..723e946a78f40 100644
> > --- a/net/netfilter/nf_conntrack_proto_tcp.c
> > +++ b/net/netfilter/nf_conntrack_proto_tcp.c
> > @@ -1281,8 +1281,9 @@ int nf_conntrack_tcp_packet(struct nf_conn *ct,
> >  	if (ct->proto.tcp.retrans >= tn->tcp_max_retrans &&
> >  	    timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
> >  		timeout = timeouts[TCP_CONNTRACK_RETRANS];
> > -	else if (unlikely(index == TCP_RST_SET))
> > -		timeout = timeouts[TCP_CONNTRACK_CLOSE];
> > +	else if (unlikely(index == TCP_RST_SET &&
> > +			  new_state == TCP_CONNTRACK_ESTABLISHED))
> > +		timeout = timeouts[TCP_CONNTRACK_UNACK];
> 
> [Severity: Medium]
> Can this new branch lengthen an entry's lifetime rather than shorten it?

Yes, it is indeed extending the timeout rather intentionally.

> Every sibling branch in this chain only assigns when the replacement is
> smaller, for example the RETRANS branch just above and the UNACK branch just
> below:
> 
>     if (ct->proto.tcp.retrans >= tn->tcp_max_retrans &&
>         timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
>         timeout = timeouts[TCP_CONNTRACK_RETRANS];
>     ...
>     else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
>          IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
>          timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
>         timeout = timeouts[TCP_CONNTRACK_UNACK];
> 
> The new branch has no such guard.  Since this branch is only reachable via
> "new_state = old_state;" in case TCP_CONNTRACK_CLOSE, new_state is
> ESTABLISHED here, so the effective comparison is timeouts[UNACK] against
> timeouts[ESTABLISHED].
> 
> With the defaults in tcp_timeouts (ESTABLISHED 5 DAYS, UNACK 5 MINS) this is
> always a lowering.

Yes, and it is intentional, this is lowering the timeout indeed.

Actually, it is lowering it in a less "aggressive" way, instead of
using CLOSE timeout it uses the UNACK timeout (5 MINS) to avoid

> But both values are independently tunable with no cross-validation:
> 
>     net/netfilter/nf_conntrack_standalone.c:
>     [NF_SYSCTL_CT_PROTO_TIMEOUT_TCP_ESTABLISHED] = {
>         .procname	= "nf_conntrack_tcp_timeout_established",
>         .maxlen		= sizeof(unsigned int),
>         .mode		= 0644,
>         .proc_handler	= proc_dointvec_jiffies,
>     },
> 
> and tcp_timeout_nlattr_to_obj() copies CTA_TIMEOUT_TCP_* verbatim.  So an
> administrator lowering nf_conntrack_tcp_timeout_established (120 s is a
> common hardening/NAT-appliance setting) inverts the relation.
> 
> __nf_ct_refresh_acct() then writes the expiry absolutely rather than
> clamping it:
> 
>     net/netfilter/nf_conntrack_core.c:__nf_ct_refresh_acct() {
>         ...
>         if (nf_ct_is_confirmed(ct))
>             extra_jiffies += nfct_time_stamp;
> 
>         if (READ_ONCE(ct->timeout) != extra_jiffies)
>             WRITE_ONCE(ct->timeout, extra_jiffies);
>         ...
>     }
> 
> In that configuration, an in-window RST whose sequence does not match
> td_maxack pushes the entry past the configured ESTABLISHED policy, and a
> periodic stream of such RSTs can renew it indefinitely, holding entries
> against nf_conntrack_max.  Would the usual form keep the intent while
> avoiding this?
> 
>     timeout = min(timeouts[new_state], timeouts[TCP_CONNTRACK_UNACK]);
> 
> or the matching guard:
> 
>     else if (unlikely(index == TCP_RST_SET &&
>                       new_state == TCP_CONNTRACK_ESTABLISHED) &&
>              timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
> 
> >  	else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
> >  		 IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
> >  		 timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
> 
> [Severity: Low]
> For an RST that conntrack does accept as closing the flow, is the CLOSE
> timeout really preserved?

No, and it is intentional. We are changing to the UNACK timeout which
is less aggresive.

> Previously such packets took the unconditional
> timeouts[TCP_CONNTRACK_CLOSE] assignment; now they fall through into the
> DATA_UNACKNOWLEDGED and last_win == 0 branches:
> 
>     else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
>          IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
>          timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
>         timeout = timeouts[TCP_CONNTRACK_UNACK];
>     else if (ct->proto.tcp.last_win == 0 &&
>          timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
>         timeout = timeouts[TCP_CONNTRACK_RETRANS];
> 
> Those fire precisely when nf_conntrack_tcp_timeout_close is raised above
> nf_conntrack_tcp_timeout_unacknowledged or the retrans timeout, and both
> preconditions are reachable for a closing RST: IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED
> is commonly set on a flow that carried data, and ct->proto.tcp.last_win is
> sticky since it is only refreshed for ACK-only segments.
> 
> This also diverges from the other closing path in the same file, which does
> not cap:
> 
>     nf_conntrack_tcp_set_closing() {
>         ...
>         timeout = timeouts[TCP_CONNTRACK_CLOSE];
>         WRITE_ONCE(ct->timeout, timeout + nfct_time_stamp);
>         ...
>     }
> 
> Given that, is the changelog sentence "Exact-match RSTs and accepted RST
> packet trains still fall through to timeouts[new_state], which preserves the
> CLOSE timeout when conntrack accepts the RST as closing the flow" accurate
> for non-default close timeouts?  Restoring an explicit CLOSE assignment for
> new_state == TCP_CONNTRACK_CLOSE, or adjusting the wording, would resolve
> it.

Not sure what wording adjustment need to be done here.

Re: [PATCH net-next 7/9] netfilter: flowtable: release tunnel route on error when building forward path

[Pablo Neira Ayuso]

Hi,

On Tue, Aug 04, 2026 at 05:19:06PM -0700, Jakub Kicinski wrote:
[...]
> [Severity: High]
> Can the dst installed here end up belonging to a different address family
> than the flow it is attached to?

Yes, the extra check to ensure IPv4 over IPv6 does not end up with the
wrong route is really required, LLM is right here.

But such check will last not long because Lorenzo's Bianconi has been
working on ip over ipv6 series for the tunneling.

I think this is not a reason to stall this net-next series, and
I think this can be done it a follow up?

Reading the two comments on patches in this net-next PR, this is the
only one that is really an issue and I think it can be addressed in a
follow up.

> The removed nft_flow_tunnel_update_route() derived the replacement dst from
> nf_route(nft_net(pkt), &tun_dst, &fl, false, nft_pf(pkt)), so the dst family
> always matched the flow's l3proto.  The dst that now arrives in
> info.tun_dst follows the tunnel underlay instead:
> 
> net/ipv4/ipip.c:ipip_fill_forward_path() always stores an IPv4 rtable:
> 
> 	path->tun.l3_proto = IPPROTO_IPIP;
> 	path->tun.dst = &rt->dst;
> 
> net/ipv6/ip6_tunnel.c:ip6_tnl_fill_forward_path() always stores an IPv6
> rt6_info:
> 
> 	path->tun.l3_proto = IPPROTO_IPV6;
> 	path->tun.dst = dst;
> 
> Neither handler consults the tunnel payload proto, and neither
> nft_dev_path_info() nor nft_dev_forward_path() checks the family before
> storing it in route->tuple[dir].dst.
> 
> The consumers cast that dst according to the inner flow family.  In
> net/netfilter/nf_flow_table_ip.c:nf_flow_offload_ipv6_hook():
> 
> 	rt = dst_rt6_info(tuplehash->tuple.dst_cache);
> 	...
> 	neigh = ip_neigh_gw6(rt->dst.dev, rt6_nexthop(rt, ip6_daddr));
> 
> and in nf_flow_offload_ip_hook():
> 
> 	rt = dst_rtable(tuplehash->tuple.dst_cache);
> 	... rt_nexthop(rt, ip_daddr) ...
> 
> net/netfilter/nf_flow_table_core.c:flow_offload_dst_cookie() does the same:
> 
> 	if (flow_tuple->l3proto == NFPROTO_IPV6)
> 		return rt6_get_cookie(dst_rt6_info(flow_tuple->dst_cache));
> 
> For an ip6_tunnel in ip4ip6 mode (t->parms.proto == IPPROTO_IPIP) carrying
> IPv4 flows, ip6_tnl_fill_forward_path() still reports l3_proto =
> IPPROTO_IPV6 and hands out an rt6_info, which nf_flow_offload_ip_hook()
> then reads through dst_rtable() and rt_nexthop()/ip_mtu_locked().  That
> configuration needs no misconfiguration to reach.
> 
> The mirror case is an IPv6 flow routed out an ipip device: an ipip device
> with mtu 1480 gets an inet6_dev at NETDEV_REGISTER, so fib6_nh_init()
> accepts "ip -6 route add ... dev tunlX", and nft_dev_fill_forward_path()
> deliberately skips the ether-device requirement for tunnels, so
> ipip_fill_forward_path() hands back an rtable that becomes the dst_cache of
> an IPv6 flow.  rt6_nexthop() then reads rt6i_flags and rt6i_gateway past
> the end of a struct rtable allocated from the ip_dst_cache slab, and the
> result is used as the IPv6 next hop passed to ip_neigh_gw6().
> 
> nf_flow_dst_check() does not catch this either: dst->ops->check() for the
> stored rtable is ipv4_dst_check(), which only tests rt_is_expired().
> 
> Would it make sense to validate info.tun.l3_proto (or the dst's
> ops->family) against the flow's l3proto before installing info.tun_dst?
> 
> [Severity: Low]
> Should this carry a Fixes: tag?

No, and it is intentional.

I already noted this rare bug while working on this series which
results in an incorrect fastpath in case route goes away while flow
offload entry is being set up, but these tunneling support is recent,
and I really preferred to go for net-next.

That was a deliberate decision. Patches with Fixes: are picked more
quickly into -stable and I did not deem this to be urgent.

> Before this change the tunnel information was only installed when the
> second lookup succeeded:
> 
> 	if (info.num_tuns &&
> 	    !nft_flow_tunnel_update_route(pkt, &info.tun, route, dir)) {
> 
> while route->tuple[!dir].in.ifindex, route->tuple[dir].out.ifindex, the
> encaps, h_source/h_dest and xmit_type had already been written and
> nft_dev_forward_path() still returned 0.  On nf_route() failure the flow was
> offloaded with the underlay device as output but num_tuns == 0, so inner
> packets left the underlay without IPIP/IP6IP6 encapsulation, which matches
> the "incomplete forward path" described in the commit message.
> 
> git blame points that construct at d30301ba4b07ac ("netfilter: flowtable:
> tunnel route update"), with the tunnel forward path support itself from
> ab427db1788581, so the bug is in released kernels rather than in-flight
> code from this series.  A Fixes: d30301ba4b07ac tag would help stable
> tracking.
> 
> It may also be worth noting in the changelog that this is not standalone
> backportable: neither dev_fill_forward_path_release() nor the
> net_device_path tun.dst field exist before the earlier "net: pass dst via
> net_device_path in dev_fill_forward_path()" commit in this series.

Re: [PATCH net-next 0/9] Netfilter updates for net-next

[Pablo Neira Ayuso]

Hi,

After reading sashiko's comment, I think this nf-next PR can be
included upstream and the only real issue can be addressed in a follow
up.

Thanks.

Re: [PATCH net-next 1/9] netfilter: conncount: normalize tuple and zone on successful ct lookup

[patchwork-bot+netdevbpf]

Hello:

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

On Fri, 31 Jul 2026 17:33:54 +0200 you wrote:
> From: Fernando Fernandez Mancera <fmancera@suse.de>
> 
> When get_ct_or_tuple_from_skb() falls back to looking for a connection
> via nf_conntrack_find_get(), a successful lookup sets ct but leaves
> tuple and zone unupdated.
> 
> If the packet belongs to a reply flow, tuple will remain in the reply
> direction. As conncount relies on the original direction tuple to count
> the connections consistenly, passing an unnormalized reply tuple could
> lead to problems.
> 
> [...]

Here is the summary with links:
  - [net-next,1/9] netfilter: conncount: normalize tuple and zone on successful ct lookup
    https://git.kernel.org/netdev/net-next/c/e53932f0e5de
  - [net-next,2/9] netfilter: flowtable: consolidate net_device field in nft_forward_info struct
    https://git.kernel.org/netdev/net-next/c/f19fd12143db
  - [net-next,3/9] netfilter: flowtable: consolidate flowtable device check
    https://git.kernel.org/netdev/net-next/c/df1705f289ba
  - [net-next,4/9] net: dsa: stop at the user device in .fill_forward_path
    https://git.kernel.org/netdev/net-next/c/5be6e044bea6
  - [net-next,5/9] net: do not advance stack index from dev_fwd_path()
    https://git.kernel.org/netdev/net-next/c/5deda60c56ee
  - [net-next,6/9] net: pass dst via net_device_path in dev_fill_forward_path()
    https://git.kernel.org/netdev/net-next/c/0ad8404e7766
  - [net-next,7/9] netfilter: flowtable: release tunnel route on error when building forward path
    https://git.kernel.org/netdev/net-next/c/806273fcaffb
  - [net-next,8/9] netfilter: nf_tables: call skb_valid_dst() before skb_dst()
    https://git.kernel.org/netdev/net-next/c/689db98e535b
  - [net-next,9/9] netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
    https://git.kernel.org/netdev/net-next/c/bf80e6802273

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