From: David Carlier <devnexen@gmail.com>
To: netfilter-devel@vger.kernel.org
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Florian Westphal <fw@strlen.de>,
Lorenzo Bianconi <lorenzo@kernel.org>,
coreteam@netfilter.org, David Carlier <devnexen@gmail.com>
Subject: [PATCH nf] netfilter: flowtable: fix IP6IP6 tunnel offset double-count with vlan/pppoe encap
Date: Thu, 4 Jun 2026 22:17:00 +0100 [thread overview]
Message-ID: <20260604211700.253946-1-devnexen@gmail.com> (raw)
nf_flow_ip6_tunnel_proto() stores the return value of ipv6_skip_exthdr()
directly into ctx->tun.hdr_size and then does ctx->offset +=
ctx->tun.hdr_size.
ipv6_skip_exthdr() returns an offset measured from skb->data, i.e. its
result already includes the "sizeof(*ip6h) + ctx->offset" start argument.
So hdr_size ends up containing ctx->offset, and the subsequent
"ctx->offset += ctx->tun.hdr_size" counts the encap offset twice.
This is harmless for a bare IP6IP6 packet, where ctx->offset is 0 on
entry, which is why it has gone unnoticed. But nf_flow_skb_encap_protocol()
advances ctx->offset by VLAN_HLEN / PPPOE_SES_HLEN before the tunnel
parser runs, so for an IP6IP6 flow carried over vlan or pppoe both
ctx->offset and ctx->tun.hdr_size are off by the encap length:
- nf_flow_tuple_ipv6() then reads the inner header at the wrong offset,
the computed tuple no longer matches the flowtable entry, and the
packet silently falls back to the slow path (IP6IP6 rx acceleration
stops working);
- on the forward path nf_flow_ip_tunnel_pop() would skb_pull() past the
inner header.
The IPv4 sibling nf_flow_ip4_tunnel_proto() does this correctly: it stores
a relative header length (iph->ihl << 2) and adds that to ctx->offset.
Make the IPv6 path symmetric by storing the relative size.
Fixes: d98103575dcd ("netfilter: flowtable: Add IP6IP6 rx sw acceleration")
Signed-off-by: David Carlier <devnexen@gmail.com>
---
net/netfilter/nf_flow_table_ip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
index 9c05a50d6013..4c6a68765c6b 100644
--- a/net/netfilter/nf_flow_table_ip.c
+++ b/net/netfilter/nf_flow_table_ip.c
@@ -366,7 +366,7 @@ static bool nf_flow_ip6_tunnel_proto(struct nf_flowtable_ctx *ctx,
return false;
if (nexthdr == IPPROTO_IPV6) {
- ctx->tun.hdr_size = hdrlen;
+ ctx->tun.hdr_size = hdrlen - ctx->offset;
ctx->tun.proto = IPPROTO_IPV6;
}
ctx->offset += ctx->tun.hdr_size;
--
2.53.0
next reply other threads:[~2026-06-04 21:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 21:17 David Carlier [this message]
2026-06-05 13:53 ` [PATCH nf] netfilter: flowtable: fix IP6IP6 tunnel offset double-count with vlan/pppoe encap Lorenzo Bianconi
2026-06-05 15:17 ` Pablo Neira Ayuso
2026-06-05 15:26 ` Lorenzo Bianconi
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=20260604211700.253946-1-devnexen@gmail.com \
--to=devnexen@gmail.com \
--cc=coreteam@netfilter.org \
--cc=fw@strlen.de \
--cc=lorenzo@kernel.org \
--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.