kernel/git/next/linux-next.git/net/ipv4/ipip.c, branch stable

ipip: fix skb leak in collect_md mode when metadata_dst allocation fails

2026-08-22T20:03:10+00:00

In collect_md mode ipip_tunnel_rcv() returns 0 without freeing the skb when ip_tun_rx_dst() fails to allocate the metadata_dst. ipip_rcv() and mplsip_rcv() are registered as xfrm_tunnel handlers, so tunnel4_rcv() and tunnelmpls4_rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked. The other tunnel drivers all dispose of the packet at this point: ip6_tunnel.c jumps to its drop label, ip_gre.c and ip6_gre.c return PACKET_REJECT, which makes gre_rcv() free the skb. Only ipip returns 0. Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it. Triggering this needs an ipip or mplsip tunnel in collect_md mode and an atomic allocation failure, which is why it has gone unnoticed. Fixes: cfc7381b3002 ("ip_tunnel: add collect_md mode to IPIP tunnel") Cc: stable@vger.kernel.org Signed-off-by: Anton Danilov Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260819104338.432631-2-littlesmilingcloud@gmail.com Signed-off-by: Jakub Kicinski

netfilter: flowtable: rename tun.l3_proto to tun.inner_proto

2026-08-10T11:02:37+00:00

This field refers to the inner protocol that is encapsulated by the tunnel header, just a comestic change. No functional changes are expected. Acked-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso

net: netfilter: add ether_type to net_device_path_ctx and use it

2026-08-10T11:02:28+00:00

Add an ether_type field to struct net_device_path_ctx to reject IPv4 over IPv6 and vice-versa, this is currently not support. Otherwise, incorrect dst_entry family can be reached from datapath. Acked-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso

netfilter: flowtable: release tunnel route on error when building forward path

2026-07-31T12:47:03+00:00

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 Signed-off-by: Pablo Neira Ayuso

ipip: reject unsupported configurations in fill_forward_path

2026-07-30T11:11:09+00:00

The ipip fill_forward_path callback currently does not check for configurations that cannot be offloaded to hardware: - Collect metadata (flow-based) tunnels have no fixed destination and rely on per-packet tunnel metadata, so the forward path cannot be pre-computed. - TOS inheritance (parms.iph.tos & 0x1) requires copying the outer TOS from the inner packet at encapsulation time, which is not known during forward path resolution. Return -EOPNOTSUPP for both cases to fall back to the software forwarding path. Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260725-ipip-fill-forward-path-fix-v1-1-bc69fd3127d5@kernel.org Signed-off-by: Paolo Abeni

net: ipip: use tunnel parameters for fill_forward_path route lookup

2026-07-21T10:33:34+00:00

Pass source address, DSCP and output interface from the tunnel configuration to ip_route_output() in ipip_fill_forward_path(), aligning the route lookup with the slow path in ipip_tunnel_xmit(). Signed-off-by: Lorenzo Bianconi Reviewed-by: David Ahern Link: https://patch.msgid.link/20260708-ipip-route-lookup-fill_forward_path-v1-1-b77df74822ed@kernel.org Signed-off-by: Paolo Abeni

net: ipip: require CAP_NET_ADMIN in the device netns for changelink

2026-06-17T23:01:52+00:00

ipip_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. Reported-by: Xiao Liang Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/ Fixes: 6c742e714d8c ("ipip: add x-netns support") Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260612085941.3158249-3-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski

ip_tunnel: annotate data-races around t->err_count and t->err_time

2026-06-12T23:40:32+00:00

ip_tunnel_xmit() runs locklessly (dev->lltx == true). ipgre_err() and ipip_err() also run locklessly. We need to add READ_ONCE() and WRITE_ONCE() annotations around t->err_count and t->err_time. Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260611165247.2710257-1-edumazet@google.com Signed-off-by: Jakub Kicinski

netfilter: flowtable: Add IPIP rx sw acceleration

2025-11-28T00:00:38+00:00

Introduce sw acceleration for rx path of IPIP tunnels relying on the netfilter flowtable infrastructure. Subsequent patches will add sw acceleration for IPIP tunnels tx path. This series introduces basic infrastructure to accelerate other tunnel types (e.g. IP6IP6). IPIP rx sw acceleration can be tested running the following scenario where the traffic is forwarded between two NICs (eth0 and eth1) and an IPIP tunnel is used to access a remote site (using eth1 as the underlay device): ETH0 -- TUN0 <==> ETH1 -- [IP network] -- TUN1 (192.168.100.2) $ip addr show 6: eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:00:22:33:11:55 brd ff:ff:ff:ff:ff:ff inet 192.168.0.2/24 scope global eth0 valid_lft forever preferred_lft forever 7: eth1: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:11:22:33:11:55 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 scope global eth1 valid_lft forever preferred_lft forever 8: tun0@NONE: mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000 link/ipip 192.168.1.1 peer 192.168.1.2 inet 192.168.100.1/24 scope global tun0 valid_lft forever preferred_lft forever $ip route show default via 192.168.100.2 dev tun0 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 192.168.100.0/24 dev tun0 proto kernel scope link src 192.168.100.1 $nft list ruleset table inet filter { flowtable ft { hook ingress priority filter devices = { eth0, eth1 } } chain forward { type filter hook forward priority filter; policy accept; meta l4proto { tcp, udp } flow add @ft } } Reproducing the scenario described above using veths I got the following results: - TCP stream received from the IPIP tunnel: - net-next: (baseline) ~ 71Gbps - net-next + IPIP flowtbale support: ~101Gbps Signed-off-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso

ipv4: ip_tunnel: Convert ip_tunnel_delete_nets() callers to ->exit_rtnl().

2025-04-15T00:08:42+00:00

ip_tunnel_delete_nets() iterates the dying netns list and performs the same operations for each. Let's export ip_tunnel_destroy() as ip_tunnel_delete_net() and call it from ->exit_rtnl(). Signed-off-by: Kuniyuki Iwashima Reviewed-by: David Ahern Reviewed-by: Sabrina Dubroca Link: https://patch.msgid.link/20250411205258.63164-7-kuniyu@amazon.com Signed-off-by: Jakub Kicinski