From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org, chzhengyang2023@lzu.edu.cn
Subject: Re: [PATCH nf 1/3] netfilter: flowtable: use dst in this direction when pushing IPIP header
Date: Mon, 29 Jun 2026 17:17:25 +0200 [thread overview]
Message-ID: <akKMhZo9OFQisGiw@lore-desk> (raw)
In-Reply-To: <20260629143936.61239-2-pablo@netfilter.org>
[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]
On Jun 29, Pablo Neira Ayuso wrote:
> When pushing the IPIP header, the route of the other direction is used
> to calculate the headroom, use the route in this direction. Accessing
> the other tuple to set the IP source and destination is fine because
> this tuple does not provide such information to avoid storing redundant
> information. However, this tuple already provides the dst for this
> direction, this went unnoticed because this bug affects headroom and
> iph->frag_off only at this stage.
>
> Fixes: d30301ba4b07 ("netfilter: flowtable: Add IPIP tx sw acceleration")
> Fixes: 93cf357fa797 ("netfilter: flowtable: Add IP6IP6 tx sw acceleration")
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> net/netfilter/nf_flow_table_ip.c | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
> index 29e93ac1e2e4..089f2bc19972 100644
> --- a/net/netfilter/nf_flow_table_ip.c
> +++ b/net/netfilter/nf_flow_table_ip.c
> @@ -590,10 +590,10 @@ static int nf_flow_pppoe_push(struct sk_buff *skb, u16 id,
>
> static int nf_flow_tunnel_ipip_push(struct net *net, struct sk_buff *skb,
> struct flow_offload_tuple *tuple,
> - __be32 *ip_daddr)
> + struct dst_entry *dst, __be32 *ip_daddr)
> {
> struct iphdr *iph = (struct iphdr *)skb_network_header(skb);
> - struct rtable *rt = dst_rtable(tuple->dst_cache);
> + struct rtable *rt = dst_rtable(dst);
> u8 tos = iph->tos, ttl = iph->ttl;
> __be16 frag_off = iph->frag_off;
> u32 headroom = sizeof(*iph);
> @@ -636,21 +636,22 @@ static int nf_flow_tunnel_ipip_push(struct net *net, struct sk_buff *skb,
>
> static int nf_flow_tunnel_v4_push(struct net *net, struct sk_buff *skb,
> struct flow_offload_tuple *tuple,
> - __be32 *ip_daddr)
> + struct dst_entry *dst, __be32 *ip_daddr)
> {
> if (tuple->tun_num)
> - return nf_flow_tunnel_ipip_push(net, skb, tuple, ip_daddr);
> + return nf_flow_tunnel_ipip_push(net, skb, tuple, dst, ip_daddr);
>
> return 0;
> }
>
> static int nf_flow_tunnel_ip6ip6_push(struct net *net, struct sk_buff *skb,
> struct flow_offload_tuple *tuple,
> + struct dst_entry *dst,
> struct in6_addr **ip6_daddr)
> {
> struct ipv6hdr *ip6h = (struct ipv6hdr *)skb_network_header(skb);
> - struct rtable *rt = dst_rtable(tuple->dst_cache);
> __u8 dsfield = ipv6_get_dsfield(ip6h);
> + struct rtable *rt = dst_rtable(dst);
> struct flowi6 fl6 = {
> .daddr = tuple->tun.src_v6,
> .saddr = tuple->tun.dst_v6,
> @@ -696,10 +697,11 @@ static int nf_flow_tunnel_ip6ip6_push(struct net *net, struct sk_buff *skb,
>
> static int nf_flow_tunnel_v6_push(struct net *net, struct sk_buff *skb,
> struct flow_offload_tuple *tuple,
> + struct dst_entry *dst,
> struct in6_addr **ip6_daddr)
> {
> if (tuple->tun_num)
> - return nf_flow_tunnel_ip6ip6_push(net, skb, tuple, ip6_daddr);
> + return nf_flow_tunnel_ip6ip6_push(net, skb, tuple, dst, ip6_daddr);
>
> return 0;
> }
> @@ -842,7 +844,8 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb,
> other_tuple = &flow->tuplehash[!dir].tuple;
> ip_daddr = other_tuple->src_v4.s_addr;
>
> - if (nf_flow_tunnel_v4_push(state->net, skb, other_tuple, &ip_daddr) < 0)
> + if (nf_flow_tunnel_v4_push(state->net, skb, other_tuple,
> + tuplehash->tuple.dst_cache, &ip_daddr) < 0)
> return NF_DROP;
>
> switch (tuplehash->tuple.xmit_type) {
> @@ -1158,6 +1161,7 @@ nf_flow_offload_ipv6_hook(void *priv, struct sk_buff *skb,
> ip6_daddr = &other_tuple->src_v6;
>
> if (nf_flow_tunnel_v6_push(state->net, skb, other_tuple,
> + tuplehash->tuple.dst_cache,
> &ip6_daddr) < 0)
> return NF_DROP;
>
> --
> 2.47.3
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-06-29 15:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 14:39 [PATCH nf 0/3] flowtable fixes for ipip tunnels Pablo Neira Ayuso
2026-06-29 14:39 ` [PATCH nf 1/3] netfilter: flowtable: use dst in this direction when pushing IPIP header Pablo Neira Ayuso
2026-06-29 15:17 ` Lorenzo Bianconi [this message]
2026-06-29 14:39 ` [PATCH nf 2/3] netfilter: flowtable: IPIP tunnel hardware offload is not yet support Pablo Neira Ayuso
2026-06-29 15:15 ` Lorenzo Bianconi
2026-06-29 14:39 ` [PATCH nf 3/3] netfilter: flowtable: support IPIP tunnel with direct xmit Pablo Neira Ayuso
2026-06-29 15:13 ` Lorenzo Bianconi
2026-07-01 6:44 ` [PATCH nf 0/3] flowtable fixes for ipip tunnels 陈正阳
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akKMhZo9OFQisGiw@lore-desk \
--to=lorenzo@kernel.org \
--cc=chzhengyang2023@lzu.edu.cn \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.