netdev - Re: [nf-next,v3,3/5] netfilter: flowtable: Add IP6IP6 rx sw acceleration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260117230521.990884-1-kuba@kernel.org>
Date: Sat, 17 Jan 2026 15:05:21 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: lorenzo@...nel.org
Cc: Jakub Kicinski <kuba@...nel.org>,
	shuah@...nel.org,
	kadlec@...filter.org,
	edumazet@...gle.com,
	dsahern@...nel.org,
	davem@...emloft.net,
	netfilter-devel@...r.kernel.org,
	fw@...len.de,
	coreteam@...filter.org,
	netdev@...r.kernel.org,
	phil@....cc,
	horms@...nel.org,
	linux-kselftest@...r.kernel.org,
	pablo@...filter.org,
	pabeni@...hat.com
Subject: Re: [nf-next,v3,3/5] netfilter: flowtable: Add IP6IP6 rx sw acceleration

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
netfilter: flowtable: Add IP6IP6 rx sw acceleration

This patch introduces software acceleration for the RX path of IP6IP6
tunnels using the netfilter flowtable infrastructure.

> diff --git a/net/netfilter/nf_flow_table_ip.c b/net/netfilter/nf_flow_table_ip.c
> index 7ee6b2e597c1..73ec8cb88285 100644
> --- a/net/netfilter/nf_flow_table_ip.c
> +++ b/net/netfilter/nf_flow_table_ip.c

[ ... ]

> @@ -326,10 +340,45 @@ static bool nf_flow_ip4_tunnel_proto(struct nf_flowtable_ctx *ctx,
>  	return true;
>  }
>
> -static void nf_flow_ip4_tunnel_pop(struct nf_flowtable_ctx *ctx,
> -				   struct sk_buff *skb)
> +static bool nf_flow_ip6_tunnel_proto(struct nf_flowtable_ctx *ctx,
> +				     struct sk_buff *skb)
> +{
> +#if IS_ENABLED(CONFIG_IPV6)
> +	struct ipv6hdr *ip6h, _ip6h;
> +	__be16 frag_off;
> +	u8 nexthdr;
> +	int hdrlen;
> +
> +	ip6h = skb_header_pointer(skb, ctx->offset, sizeof(*ip6h), &_ip6h);
> +	if (!ip6h)
> +		return false;
> +
> +	if (ip6h->hop_limit <= 1)
> +		return false;
> +
> +	nexthdr = ipv6_hdr(skb)->nexthdr;
                 ^^^^^^^^^^^^

When ctx->offset is non-zero (e.g., VLAN-encapsulated traffic where
nf_flow_skb_encap_protocol() sets ctx->offset += VLAN_HLEN), ip6h points
to the IPv6 header at ctx->offset, but ipv6_hdr(skb) returns
skb_network_header(skb) which is at offset 0.

Should this be ip6h->nexthdr instead of ipv6_hdr(skb)->nexthdr?

The IPv4 analog nf_flow_ip4_tunnel_proto() uses iph->protocol where iph
is calculated as (skb_network_header(skb) + ctx->offset), which correctly
accounts for the encapsulation offset.

> +	hdrlen = ipv6_skip_exthdr(skb, sizeof(*ip6h) + ctx->offset, &nexthdr,
> +				  &frag_off);
> +	if (hdrlen < 0)
> +		return false;
> +
> +	if (nexthdr == IPPROTO_IPV6) {
> +		ctx->tun.hdr_size = hdrlen;
> +		ctx->tun.proto = IPPROTO_IPV6;
> +	}
> +	ctx->offset += ctx->tun.hdr_size;
> +
> +	return true;
> +#else
> +	return false;
> +#endif /* IS_ENABLED(CONFIG_IPV6) */
> +}

[ ... ]