Netdev List
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>, netdev@vger.kernel.org
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Pirko <jiri@resnulli.us>,
	"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>,
	Victor Nogueira <victor@mojatatu.com>,
	vtahiliani@nitk.edu.in, chia-yu.chang@nokia-bell-labs.com,
	subramanian.vijay@gmail.com, vega@nebusec.ai,
	stable@vger.kernel.org
Subject: Re: [PATCH net] net/sched: clamp quantum and psched_mtu in change paths and missed siblings
Date: Wed, 26 Aug 2026 10:25:48 +0200	[thread overview]
Message-ID: <87qzjl47ar.fsf@toke.dk> (raw)
In-Reply-To: <20260826074056.7873-1-jhs@mojatatu.com>

Jamal Hadi Salim <jhs@mojatatu.com> writes:

> This is a followup to commit 709f34f7c28d ("net/sched: fq: add
> overflow bounds to quantum and initial quantum").
> The quantum_backlog_overflow series and the five siblings that followed
> clamped the init-path quantum to in fq, fq_codel, fq_pie, hhf, sfq.
> The change() paths with the same pattern, same writer of q->quantum,
> same privilege level (CAP_NET_ADMIN in a user namespace) were not clamped.
> A user can override the init clamp via tc qdisc change, restoring the
> small-quantum deficit spin that the init clamp was meant to prevent.
>
> This follow-up also covers two siblings that were missed entirely by
> the original series: sch_dualpi2 and sch_pie call psched_mtu() without
> any clamp at all. With a crafted size table qdisc_pkt_len reaches ~2
> GiB, so quantum=1 (or a zero psched_mtu on a headerless device) makes
> the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft
> lockup / denial of service).
>
> Fixes based on review of 709f34f7c28d:
>
> 1. fq_pie_change() accepts quantum=1 (NLA policy fq_pie_q_range.min=1).
>    Add max(256U, ...) matching fq_codel_change()
>    (Sashiko nipa gpt-5-6-sol-3-8 and gpt-5-6-sol-6-7)
>
> 2. sfq_change() accepts any non-negative quantum (only rejects
>    (int)ctl->quantum < 0). Add max(256U, ...) matching fq_codel_change().
>    Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and
>    the init clamp.
>    (Internal review noticing same pattern)
>
> 3. hhf_change() accepts quantum=1 (only checks non_hh_quantum product).
>    Add max(256U, ...) matching fq_codel_change()
>    (Sashiko nipa v1 review + vega@nebusec.ai independent bug)
>
> 4. fq_change() accepts TCA_FQ_INITIAL_QUANTUM up to INT_MAX (iq_range.max
>    = INT_MAX) while fq_init() now clamps to 1<<20.  Narrow iq_range.max
>    to 1<<20, rejecting at parse time.  (Eric Dumazet)
>
> 5. sch_dualpi2: dualpi2_calculate_c_protection() and get_memory_limit()
>    call psched_mtu() with no clamp. A huge MTU makes (s32)psched_mtu()
>    overflow in the signed multiply for c_protection_init, and 2 *
>    psched_mtu() wraps in get_memory_limit(). Clamp to [1, 1<<20] at
>    all three call sites. (Sashiko nipa main-6-4)
>
> 6. sch_pie: pie_drop_early() calls psched_mtu() with no clamp.  With
>    mtu=0x80000000 the bytemode divide silently zeroes the drop
>    probability, disabling AQM. Clamp to [1, 1<<20] (Sashiko gemini)
>
> 7. sch_drr: drr_change_class() rejects explicit quantum==0 but falls
>    back to psched_mtu() with no floor. Add max(256U, ...) after the
>    zero reject and on the fallback path
>   (vega@nebusec.ai independent bug)
>
> 8. sch_ets: ets_qdisc_change() falls back to psched_mtu() with no floor
>    for bands without an explicit quantum.  Add max(256U, ...) on the
>    fallback path (vega@nebusec.ai independent bug)
>
> The init paths of fq_pie, sfq, and hhf delegate to their _change() when
> opt is present, so the floor covers tc qdisc add ... quantum 1 as well
> as change. The zero-quantum-from-psched_mtu case on a headerless device
> (mtu==0) is also covered by the 256 floor in drr and ets; the
> explicit-zero reject in drr_change_class() is preserved.
>
> The sfq_change() silent clamp is user-visible: sfq_dump() reports the
> clamped quantum, so a previously accepted quantum < 256 now reads back
> as 256. Idempotent config managers that read back and compare will
> see drift. fq_codel_change() made the same trade, so this is consistent.
>
> Conditions to recreate the bug: create a fq_pie, sfq, hhf, dualpi2, or
> pie qdisc (or a drr class / ets band), then tc qdisc change ... quantum 1
> with a STAB size table inflating qdisc_pkt_len, e.g.:
>
>   tc qdisc add dev dummy0 root fq_pie
>   tc qdisc change dev dummy0 root fq_pie quantum 1 \
>     stab data 32768 size_log 15 cell_log 0
>
> Requires CAP_NET_ADMIN in a user namespace (unshare -Urn).
>
> Fixes: 709f34f7c28d ("net/sched: fq: add overflow bounds to quantum and initial quantum")
> Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler")
> Fixes: e4650d7ae425 ("net_sched: sch_sfq: handle bigger packets")
> Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc")
> Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc")
> Fixes: d4b36210c2e6 ("net: pkt_sched: PIE AQM scheme")
> Fixes: 13d2a1d2b032 ("pkt_sched: add DRR scheduler")
> Reported-by: vega@nebusec.ai
> Tested-by: Victor Nogueira <victor@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: stable@vger.kernel.org

Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>


  reply	other threads:[~2026-08-26  8:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26  7:40 [PATCH net] net/sched: clamp quantum and psched_mtu in change paths and missed siblings Jamal Hadi Salim
2026-08-26  8:25 ` Toke Høiland-Jørgensen [this message]
2026-08-27 19:34 ` Jakub Kicinski
2026-08-27 23:09   ` Jamal Hadi Salim

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=87qzjl47ar.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=chia-yu.chang@nokia-bell-labs.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=subramanian.vijay@gmail.com \
    --cc=vega@nebusec.ai \
    --cc=victor@mojatatu.com \
    --cc=vtahiliani@nitk.edu.in \
    /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