Netdev List
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <edumazet@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Willem de Bruijn <willemb@google.com>,
	Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, shaos <shawnq1@163.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [PATCH net] net: harden qdisc_pkt_len_segs_init() against malicious GSO packets
Date: Thu, 22 Oct 2026 12:03:17 -0400	[thread overview]
Message-ID: <20261022120246-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20261022155436.117507-1-edumazet@kernel.org>

On Thu, Oct 22, 2026 at 05:54:36PM +0200, Eric Dumazet wrote:
> 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>

I'm all for stack being more resilient.

Acked-by: 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


  reply	other threads:[~2026-10-22 16:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 15:54 [PATCH net] net: harden qdisc_pkt_len_segs_init() against malicious GSO packets Eric Dumazet
2026-10-22 16:03 ` Michael S. Tsirkin [this message]
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=20261022120246-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=jhs@mojatatu.com \
    --cc=kuba@kernel.org \
    --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