From: Phil Sutter <phil@nwl.cc>
To: Zhixing Chen <running910@gmail.com>
Cc: Florian Westphal <fw@strlen.de>,
Pablo Neira Ayuso <pablo@netfilter.org>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org
Subject: Re: [PATCH nf] netfilter: ip6tables: set hotdrop for malformed extension header matches
Date: Thu, 9 Jul 2026 13:02:25 +0200 [thread overview]
Message-ID: <ak9_wZz054a6JMb5@orbyte.nwl.cc> (raw)
In-Reply-To: <20260709063012.33160-1-running910@gmail.com>
Hi,
On Thu, Jul 09, 2026 at 02:30:12PM +0800, Zhixing Chen wrote:
> The hbh, srh and ipv6header matches have paths that return false for
> malformed IPv6 extension header packets without setting hotdrop.
>
> For hbh, strict option parsing stops when the option type or length field
> cannot be read, or when advancing to the next requested option would
> exceed the available header data. Mark these packets for hotdrop instead
> of treating them as a rule mismatch.
There is another candidate for hotdrop in there, e.g. the "Packet
smaller than it's length field" check in line 76. Or is this a
legitimate non-match?
Given the many common blocks, maybe introduce a 'hotdrop' goto label to
jump to instead of break/return?
>
> For srh, keep a missing SRH as a normal mismatch, but set hotdrop when
> header lookup fails for other reasons, when the SRH fixed header is not
> present, when the advertised SRH length exceeds the available skb data, or
> when SID selector reads fail.
I think the 'srh->segments_left > srh->first_segment' case is also a
candidate:
According to RFC8200, segments_left contains the "Number of route
segments remaining, i.e., number of explicitly listed intermediate nodes
still to be visited before reaching the final destination."
RFC8754 reads: "Last Entry: contains the index (zero based), in the
Segment List, of the last element of the Segment List." ('first_segment'
is called Last Entry in there.)
AIUI, segments_left should never exceed first_segment in a packet.
Though RFC8754 mentions a case where "Segments Left is greater than Last
Entry", but it's about HMAC verification and it doesn't explain why it
should happen.
[...]
> diff --git a/net/ipv6/netfilter/ip6t_ipv6header.c b/net/ipv6/netfilter/ip6t_ipv6header.c
> index c52ff929c93b..0568eb99eb1c 100644
> --- a/net/ipv6/netfilter/ip6t_ipv6header.c
> +++ b/net/ipv6/netfilter/ip6t_ipv6header.c
> @@ -53,8 +53,10 @@ ipv6header_mt6(const struct sk_buff *skb, struct xt_action_param *par)
> break;
> }
> /* Is there enough space for the next ext header? */
> - if (len < (int)sizeof(struct ipv6_opt_hdr))
> + if (len < (int)sizeof(struct ipv6_opt_hdr)) {
> + par->hotdrop = true;
> return false;
> + }
This check is actually redundant, no? The following call to
skb_header_pointer() should discover the skb->len underrun?
Cheers, Phil
next prev parent reply other threads:[~2026-07-09 11:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 6:30 [PATCH nf] netfilter: ip6tables: set hotdrop for malformed extension header matches Zhixing Chen
2026-07-09 11:02 ` Phil Sutter [this message]
2026-07-13 3:10 ` Zhixing Chen
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=ak9_wZz054a6JMb5@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=running910@gmail.com \
/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.