From: Eric Dumazet <edumazet@kernel.org>
To: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Willem de Bruijn <willemb@google.com>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, Eric Dumazet <edumazet@kernel.org>,
shaos <shawnq1@163.com>, Jamal Hadi Salim <jhs@mojatatu.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: [PATCH net] net: harden qdisc_pkt_len_segs_init() against malicious GSO packets
Date: Thu, 22 Oct 2026 17:54:36 +0200 [thread overview]
Message-ID: <20261022155436.117507-1-edumazet@kernel.org> (raw)
An SKB_GSO_DODGY packet can carry untrusted gso_size and headers.
For instance, gso_size=1 and hdr_len=65532 for a 524275-byte frame
makes qdisc_pkt_len_segs_init() compute an accounted length of
about 4,294,574,091 bytes (after gso_segs silently wrapped in a u16).
With DRR quantum 256, the dequeue path then needs ~16.8 million
deficit refills before it can dequeue the skb, keeping the CPU in
the qdisc path long enough to trigger the soft-lockup watchdog.
Commit 8f735d64382d ("net/sched: bound qdisc_pkt_len to prevent
qdisc soft lockup") added QDISC_PKT_LEN_MAX to bound size table
amplification. Use the same bound for DODGY packets:
- Make gso_segs a u32 and drop packets whose segment count does
not fit GSO_MAX_SEGS, instead of silently truncating it.
- Drop packets whose estimated qdisc_pkt_len() would exceed
QDISC_PKT_LEN_MAX.
Fixes: 15e5a0307164 ("net_sched: better precise estimation on packet length for untrusted packets")
Reported-by: shaos <shawnq1@163.com>
Closes: https://lore.kernel.org/netdev/20261022144755.65025-1-shawnq1@163.com/
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
---
net/core/dev.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index e76762e29360ea87ade0846e4a4f9016dca587d6..573bcc9d67b1b1e21e844f054f0b51a172713a90 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4175,7 +4175,7 @@ static enum skb_drop_reason qdisc_pkt_len_segs_init(struct sk_buff *skb)
{
struct skb_shared_info *shinfo = skb_shinfo(skb);
unsigned int hdr_len, tlen;
- u16 gso_segs;
+ u32 gso_segs;
qdisc_skb_cb(skb)->pkt_len = skb->len;
if (!shinfo->gso_size) {
@@ -4226,6 +4226,15 @@ static enum skb_drop_reason qdisc_pkt_len_segs_init(struct sk_buff *skb)
if (payload <= 0)
return SKB_DROP_REASON_SKB_BAD_GSO;
gso_segs = DIV_ROUND_UP(payload, shinfo->gso_size);
+ /* shinfo->gso_segs is a 16bit field.
+ * Also make sure untrusted gso_size/hdr_len can not inflate
+ * qdisc_pkt_len() beyond QDISC_PKT_LEN_MAX, or deficit
+ * schedulers could spin in their refill loops.
+ */
+ if (unlikely(gso_segs > GSO_MAX_SEGS ||
+ skb->len + (u64)(gso_segs - 1) * hdr_len >
+ QDISC_PKT_LEN_MAX))
+ return SKB_DROP_REASON_SKB_BAD_GSO;
shinfo->gso_segs = gso_segs;
qdisc_skb_cb(skb)->pkt_segs = gso_segs;
}
--
2.53.0
next reply other threads:[~2026-10-22 15:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 15:54 Eric Dumazet [this message]
2026-10-22 16:03 ` [PATCH net] net: harden qdisc_pkt_len_segs_init() against malicious GSO packets Michael S. Tsirkin
2026-10-23 1:29 ` Willem de Bruijn
2026-10-26 23:30 ` 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=20261022155436.117507-1-edumazet@kernel.org \
--to=edumazet@kernel.org \
--cc=davem@davemloft.net \
--cc=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=kuba@kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shawnq1@163.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