From: Eric Dumazet <edumazet@kernel.org>
To: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Willem de Bruijn <willemb@google.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, edumazet@google.com,
Eric Dumazet <edumazet@kernel.org>
Subject: [PATCH v3 net 1/3] flow_dissector: avoid u16 truncation of skb->len when computing thoff
Date: Thu, 1 Oct 2026 19:11:38 +0000 [thread overview]
Message-ID: <20261001191140.2818991-2-edumazet@kernel.org> (raw)
In-Reply-To: <20261001191140.2818991-1-edumazet@kernel.org>
__skb_flow_dissect() computes key_control->thoff using:
key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
min_t(u16, ...) casts both arguments to u16 before comparing them.
Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the
truncated length wins and thoff is set to a bogus small value, even
when the dissection succeeded. For example, an IPv4/TCP frame with
skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as
skb_probe_transport_header() point the transport header inside the
Ethernet header.
Such skbs are not exotic:
- At the time of commit d0c081b49137 ("flow_dissector: properly cap
thoff field"), AF_PACKET with PACKET_VNET_HDR could already build GSO
skbs larger than 64KB (MTU checks are skipped for GSO, and
alloc_skb_with_frags() accepted up to MAX_SKB_FRAGS (17) order-0
pages on top of the linear part).
- BIG TCP now makes skbs larger than 64KB common.
- The following patch makes tun_get_user() dissect IFF_TAP frames
before eth_type_trans() pulls the Ethernet header, so a GSO frame
carrying a 65522..65535 byte L3 packet will be dissected with
skb->len in [65536, 65549].
Compare as u32 instead. If the resulting offset cannot be represented
in the u16 key_control->thoff, cap it to U16_MAX and report the
dissection as failed rather than silently returning a wrong transport
offset. thoff is still set on failure, as some callers (such as
eth_get_headlen()) use it regardless of the return value.
Fixes: d0c081b49137 ("flow_dissector: properly cap thoff field")
Assisted-by: LLM
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
---
net/core/flow_dissector.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 8aa4f9b4df81016a3d9a97e0d561f6dfc51aa88d..27d8a01bc92306ff043389b4fde2d24af97d3106 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -1071,6 +1071,7 @@ bool __skb_flow_dissect(const struct net *net,
int mpls_lse = 0;
int num_hdrs = 0;
u8 ip_proto = 0;
+ u32 thoff;
bool ret;
if (!data) {
@@ -1692,7 +1693,13 @@ bool __skb_flow_dissect(const struct net *net,
ret = true;
out:
- key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
+ thoff = min_t(u32, nhoff, skb ? skb->len : hlen);
+ if (unlikely(thoff > U16_MAX)) {
+ /* Cannot be represented in key_control->thoff. */
+ thoff = U16_MAX;
+ ret = false;
+ }
+ key_control->thoff = thoff;
key_basic->n_proto = proto;
key_basic->ip_proto = ip_proto;
--
2.56.0.rc1.315.gc6ed9934b7-goog
next prev parent reply other threads:[~2026-10-01 19:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 19:11 [PATCH v3 net 0/3] net: always dissect GSO packets in __virtio_net_hdr_to_skb() Eric Dumazet
2026-10-01 19:11 ` Eric Dumazet [this message]
2026-10-01 23:30 ` [PATCH v3 net 1/3] flow_dissector: avoid u16 truncation of skb->len when computing thoff Willem de Bruijn
2026-10-05 15:30 ` netdev-bot+sashiko
2026-10-05 19:38 ` Eric Dumazet
2026-10-01 19:11 ` [PATCH v3 net 2/3] net: always dissect GSO packets in __virtio_net_hdr_to_skb() Eric Dumazet
2026-10-01 19:11 ` [PATCH v3 net 3/3] selftests: net: tun: add test for VLAN-tagged GSO without NEEDS_CSUM Eric Dumazet
2026-10-01 23:37 ` Willem de Bruijn
2026-10-06 22:37 ` [PATCH v3 net 0/3] net: always dissect GSO packets in __virtio_net_hdr_to_skb() Michael S. Tsirkin
2026-10-06 23:26 ` Willem de Bruijn
2026-10-06 23:49 ` Michael S. Tsirkin
2026-10-07 0:13 ` Willem de Bruijn
2026-10-07 0:18 ` Michael S. Tsirkin
2026-10-07 0:30 ` Willem de Bruijn
2026-10-07 8:04 ` Michael S. Tsirkin
2026-10-07 14:21 ` Willem de Bruijn
2026-10-06 23:00 ` patchwork-bot+netdevbpf
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=20261001191140.2818991-2-edumazet@kernel.org \
--to=edumazet@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox