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: <CAD0BsJXNcZ0w7BViTz4t07pY7ViSNbNJx_XR4LVRtdjC-x9vCA@mail.gmail.com>
Date: Tue, 13 Jan 2026 23:28:16 +0200
From: Alice Mikityanska <alice@...valent.com>
To: Stanislav Fomichev <stfomichev@...il.com>
Cc: Maxim Mikityanskiy <maxtram95@...il.com>, Daniel Borkmann <daniel@...earbox.net>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Willem de Bruijn <willemdebruijn.kernel@...il.com>, David Ahern <dsahern@...nel.org>, 
	Nikolay Aleksandrov <razor@...ckwall.org>, netdev@...r.kernel.org, 
	tcpdump-workers@...ts.tcpdump.org, Guy Harris <gharris@...ic.net>, 
	Michael Richardson <mcr@...delman.ca>, Denis Ovsienko <denis@...ienko.info>, Xin Long <lucien.xin@...il.com>
Subject: Re: [PATCH net-next 01/17] net/ipv6: Introduce payload_len helpers

On Thu, 25 Sept 2025 at 21:23, Stanislav Fomichev <stfomichev@...il.com> wrote:
>
> On 09/23, Maxim Mikityanskiy wrote:
> > From: Maxim Mikityanskiy <maxim@...valent.com>
> >
> > From: Maxim Mikityanskiy <maxim@...valent.com>
> >
> > The next commits will transition away from using the hop-by-hop
> > extension header to encode packet length for BIG TCP. Add wrappers
> > around ip6->payload_len that return the actual value if it's non-zero,
> > and calculate it from skb->len if payload_len is set to zero (and a
> > symmetrical setter).
> >
> > The new helpers are used wherever the surrounding code supports the
> > hop-by-hop jumbo header for BIG TCP IPv6, or the corresponding IPv4 code
> > uses skb_ip_totlen (e.g., in include/net/netfilter/nf_tables_ipv6.h).
> >
> > No behavioral change in this commit.
> >
> > Signed-off-by: Maxim Mikityanskiy <maxim@...valent.com>
> > ---
> >  include/linux/ipv6.h                       | 20 ++++++++++++++++++++
> >  include/net/ipv6.h                         |  2 --
> >  include/net/netfilter/nf_tables_ipv6.h     |  4 ++--
> >  net/bridge/br_netfilter_ipv6.c             |  2 +-
> >  net/bridge/netfilter/nf_conntrack_bridge.c |  4 ++--
> >  net/ipv6/ip6_input.c                       |  2 +-
> >  net/ipv6/ip6_offload.c                     |  7 +++----
> >  net/ipv6/output_core.c                     |  7 +------
> >  net/netfilter/ipvs/ip_vs_xmit.c            |  2 +-
> >  net/netfilter/nf_conntrack_ovs.c           |  2 +-
> >  net/netfilter/nf_log_syslog.c              |  2 +-
> >  net/sched/sch_cake.c                       |  2 +-
> >  12 files changed, 34 insertions(+), 22 deletions(-)
> >
> > diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> > index 43b7bb828738..44c4b791eceb 100644
> > --- a/include/linux/ipv6.h
> > +++ b/include/linux/ipv6.h
> > @@ -126,6 +126,26 @@ static inline unsigned int ipv6_transport_len(const struct sk_buff *skb)
> >              skb_network_header_len(skb);
> >  }
> >
> > +static inline unsigned int ipv6_payload_len(const struct sk_buff *skb, const struct ipv6hdr *ip6)
> > +{
> > +     u32 len = ntohs(ip6->payload_len);
> > +
> > +     return (len || !skb_is_gso(skb) || !skb_is_gso_tcp(skb)) ?
> > +            len : skb->len - skb_network_offset(skb) - sizeof(struct ipv6hdr);
>
> Any reason not to return skb->len - skb_network_offset(skb) - sizeof(struct ipv6hdr)
> here unconditionally? Will it not work in some cases?

Just submitted a v2. Yes, it's intentional:

Many callers do extra checks that the payload length is valid, i.e.
not bigger than the SKB length. If we just use the calculation
unconditionally, those checks will always pass, even for invalid
packets that have payload_len bigger than the actual packet size.

For example, bridge and netfilter validate that an IPv6 packet either
has a non-zero payload_len that fits into the SKB, or it has a zero
payload_len and an HBH Jumbo header with a length that fits into the
SKB, or it's a new-style BIG TCP packet with a zero payload_len, hence
the checks for GRO/GSO in ipv6_payload_len(): we make sure that it
didn't come with payload_len = 0 from the wire (ipv6_gro_receive also
checks payload_len before aggregating packets).

Note that this commit aims to reflect the same behavior that we have
with IPv4 and iph_totlen.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ