From: Jakub Kicinski <kuba@kernel.org>
To: ericwouds@gmail.com
Cc: Jakub Kicinski <kuba@kernel.org>,
mostrows@earthlink.net, netfilter-devel@vger.kernel.org,
pabeni@redhat.com, kees@kernel.org, edumazet@google.com,
razor@blackwall.org, horms@kernel.org, fw@strlen.de,
pablo@netfilter.org, andrew+netdev@lunn.ch, idosch@nvidia.com,
netdev@vger.kernel.org, davem@davemloft.net,
bridge@lists.linux.dev, phil@nwl.cc
Subject: Re: [v19,nf-next,4/5] netfilter: nft_set_pktinfo_ipv4/6_validate: Add nhoff argument
Date: Tue, 24 Feb 2026 17:52:56 -0800 [thread overview]
Message-ID: <20260225015256.967692-1-kuba@kernel.org> (raw)
In-Reply-To: <20260224065307.120768-5-ericwouds@gmail.com>
This is an AI-generated review of your patch. The human sending this
email says "The tracking of feedback in the AI bot is often wrong,
but FWIW this is what it has to say about the submission"
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
netfilter: nft_set_pktinfo_ipv4/6_validate: Add nhoff argument
This commit adds the ability to specify an offset when calling
nft_set_pktinfo_ipv4/6_validate() for cases where the IP header is not
at skb_network_header().
> diff --git a/include/net/netfilter/nf_tables_ipv4.h b/include/net/netfilter/nf_tables_ipv4.h
> index fcf967286e37..bd354937134f 100644
> --- a/include/net/netfilter/nf_tables_ipv4.h
> +++ b/include/net/netfilter/nf_tables_ipv4.h
[ ... ]
> diff --git a/include/net/netfilter/nf_tables_ipv6.h b/include/net/netfilter/nf_tables_ipv6.h
> index c53ac00bb974..1e84a891f268 100644
> --- a/include/net/netfilter/nf_tables_ipv6.h
> +++ b/include/net/netfilter/nf_tables_ipv6.h
> @@ -24,17 +24,17 @@ static inline void nft_set_pktinfo_ipv6(struct nft_pktinfo *pkt)
> pkt->fragoff = frag_off;
> }
>
> -static inline int __nft_set_pktinfo_ipv6_validate(struct nft_pktinfo *pkt)
> +static inline int __nft_set_pktinfo_ipv6_validate(struct nft_pktinfo *pkt, u32 nhoff)
> {
> #if IS_ENABLED(CONFIG_IPV6)
> unsigned int flags = IP6_FH_F_AUTH;
> struct ipv6hdr *ip6h, _ip6h;
> - unsigned int thoff = 0;
> + unsigned int thoff = nhoff;
^^^^^
When nhoff != 0, does ipv6_find_hdr() interpret 'thoff' as a relative or
absolute offset?
Looking at the IPv6 header read above:
ip6h = skb_header_pointer(pkt->skb, skb_network_offset(pkt->skb) + nhoff,
sizeof(*ip6h), &_ip6h);
The IPv6 header is at absolute offset 'skb_network_offset(pkt->skb) + nhoff'.
But when ipv6_find_hdr() is called:
protohdr = ipv6_find_hdr(pkt->skb, &thoff, -1, &frag_off, &flags);
ipv6_find_hdr() interprets a non-zero *offset as an absolute offset from
skb->data (it does: ip6 = skb_header_pointer(skb, *offset, ...) and
start = *offset + sizeof(struct ipv6hdr)).
In bridge contexts where skb_network_offset != 0 (typically 14 for Ethernet),
ipv6_find_hdr() will read from the wrong location when nhoff != 0. Shouldn't
this be 'unsigned int thoff = skb_network_offset(pkt->skb) + nhoff;' to match
how the IPv6 header is read?
The IPv4 version correctly computes absolute offsets:
pkt->thoff = skb_network_offset(pkt->skb) + nhoff + thoff;
All current callers pass nhoff=0, so this is dormant until a future patch
enables non-zero nhoff (which this commit is designed to support).
> unsigned short frag_off;
> u32 pkt_len, skb_len;
> int protohdr;
>
> - ip6h = skb_header_pointer(pkt->skb, skb_network_offset(pkt->skb),
> + ip6h = skb_header_pointer(pkt->skb, skb_network_offset(pkt->skb) + nhoff,
> sizeof(*ip6h), &_ip6h);
> if (!ip6h)
> return -1;
[ ... ]
Florian Westphal raised a concern in v18 about a build warning in
include/uapi/linux/if_pppox.h:153:29 ('array of flexible structures').
He requested a new version to fix this. The author addressed this in v19 by
adding patch 1/5 'net: pppoe: avoid zero-length arrays in struct pppoe_hdr'
that wraps the flexible arrays in '#ifndef __KERNEL__' guards.
Reference: https://lore.kernel.org/netdev/aZynSuGMtK7JOOCj@strlen.de/
next prev parent reply other threads:[~2026-02-25 1:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 6:53 [PATCH v19 nf-next 0/5] conntrack: bridge: add double vlan, pppoe and pppoe-in-q Eric Woudstra
2026-02-24 6:53 ` [PATCH v19 nf-next 1/5] net: pppoe: avoid zero-length arrays in struct pppoe_hdr Eric Woudstra
2026-02-24 14:15 ` Florian Westphal
2026-02-24 6:53 ` [PATCH v19 nf-next 2/5] netfilter: utils: nf_checksum(_partial) correct data!=networkheader Eric Woudstra
2026-02-24 6:53 ` [PATCH v19 nf-next 3/5] netfilter: bridge: Add conntrack double vlan and pppoe Eric Woudstra
2026-02-25 1:52 ` [v19,nf-next,3/5] " Jakub Kicinski
2026-02-24 6:53 ` [PATCH v19 nf-next 4/5] netfilter: nft_set_pktinfo_ipv4/6_validate: Add nhoff argument Eric Woudstra
2026-02-25 1:52 ` Jakub Kicinski [this message]
2026-02-24 6:53 ` [PATCH v19 nf-next 5/5] netfilter: nft_chain_filter: Add bridge double vlan and pppoe Eric Woudstra
2026-03-10 8:37 ` Eric Woudstra
2026-03-10 12:39 ` Florian Westphal
2026-03-11 10:07 ` Pablo Neira Ayuso
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=20260225015256.967692-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ericwouds@gmail.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kees@kernel.org \
--cc=mostrows@earthlink.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=razor@blackwall.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox