Re: [PATCH net v3 4/6] net/sched: fq_pie: clamp default quantum to avoid signed overflow

Paolo Abeni <[email protected]>
Newsgroups org.kernel.vger.stable,org.kernel.vger.netdev
Message-ID <[email protected]>
Hi,

On 8/22/26 9:55 PM, Jamal Hadi Salim wrote:
> fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without
> clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0
> accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which
> overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(),
> causing an infinite loop and soft lockup. Emulate fq_pie_policy which
> is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20].
> 256 matches fq_codel's floor and is a sane minimum for a DRR quantum.
> 
> Conditions to recreate the bug: a device whose MTU (plus
> hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy
> device with max_mtu == 0 accepting MTU 2147483634). Requires
> CAP_NET_ADMIN in a user namespace.
> 
> Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler")
> Reported-by: [email protected]
> Tested-by: Victor Nogueira <[email protected]>
> Signed-off-by: Jamal Hadi Salim <[email protected]>
> ---
>  net/sched/sch_fq_pie.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/sched/sch_fq_pie.c b/net/sched/sch_fq_pie.c
> index 069e1facd413..b27d95418707 100644
> --- a/net/sched/sch_fq_pie.c
> +++ b/net/sched/sch_fq_pie.c
> @@ -427,7 +427,8 @@ static int fq_pie_init(struct Qdisc *sch, struct nlattr *opt,
>  	pie_params_init(&q->p_params);
>  	sch->limit = 10 * 1024;
>  	q->p_params.limit = sch->limit;
> -	q->quantum = psched_mtu(qdisc_dev(sch));
> +	q->quantum = clamp_t(u32, psched_mtu(qdisc_dev(sch)),
> +			     256, 1 << 20);

Sashiko thinks that the soft lookup is still reachable via pie_change:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260822195509.112717-1-jhs%40mojatatu.com

and has similar concerns for patch 6/6, too. It marks the issues as
pre-existing, but AFAICS they overlap with the things addressed here.

WDYT?

/P
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.