linux-kernel - Re: [PATCH net] net/sched: Fix possible infinite loop in qdisc_tree_reduce

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAM0EoMn-2ZzbKozqj9y=9yKJT8ANJPqO9UYoiJqFyqUoKfx8RA@mail.gmail.com>
Date: Wed, 5 Nov 2025 09:49:40 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Wang Liang <wangliang74@...wei.com>
Cc: xiyou.wangcong@...il.com, jiri@...nulli.us, davem@...emloft.net, 
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org, 
	pctammela@...atatu.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	yuehaibing@...wei.com, zhangchangzhong@...wei.com, 
	Victor Nogueira <victor@...atatu.com>
Subject: Re: [PATCH net] net/sched: Fix possible infinite loop in qdisc_tree_reduce_backlog()

On Tue, Nov 4, 2025 at 9:00 PM Wang Liang <wangliang74@...wei.com> wrote:
>
> A soft lockup issue was observed with following log:
>
>   watchdog: BUG: soft lockup - CPU#1 stuck for 104s! [tc:94]
>   CPU: 1 UID: 0 PID: 94 Comm: tc Tainted: G L 6.18.0-rc4-00007-gc9cfc122f037 #425 PREEMPT(voluntary)
>   RIP: 0010:qdisc_match_from_root+0x0/0x70
>   Call Trace:
>    <TASK>
>    qdisc_tree_reduce_backlog+0xec/0x110
>    fq_change+0x2e0/0x6a0
>    qdisc_create+0x138/0x4e0
>    tc_modify_qdisc+0x5b9/0x9d0
>    rtnetlink_rcv_msg+0x15a/0x400
>    netlink_rcv_skb+0x55/0x100
>    netlink_unicast+0x257/0x380
>    netlink_sendmsg+0x1e2/0x420
>    ____sys_sendmsg+0x313/0x340
>    ___sys_sendmsg+0x82/0xd0
>    __sys_sendmsg+0x6c/0xd0
>    </TASK>
>
> The issue can be reproduced by:
>   tc qdisc add dev eth0 root noqueue
>   tc qdisc add dev eth0 handle ffff:0 ingress
>   tc qdisc add dev eth0 handle ffe0:0 parent ffff:a fq
>
> A fq qdisc was created in __tc_modify_qdisc(), when the input parent major
> 'ffff' is equal to the ingress qdisc handle major and the complete parent
> handle is not TC_H_ROOT or TC_H_INGRESS, which leads to a infinite loop in
> qdisc_tree_reduce_backlog().
>

Good test case, but i dont think this is the right solution.
That config is bogus and should never have been accepted by the kernel.
We'll look into it..

cheers,
jamal


> The infinite loop scenario:
>
>   qdisc_tree_reduce_backlog
>
>     // init sch is fq qdisc, parent is ffff000a
>     while ((parentid = sch->parent)) {
>
>       // query qdisc by handle ffff0000
>       sch = qdisc_lookup_rcu(qdisc_dev(sch), TC_H_MAJ(parentid));
>
>       // return ingress qdisc, sch->parent is fffffff1
>       if (sch == NULL) {
>       ...
>     }
>
> Commit 2e95c4384438 ("net/sched: stop qdisc_tree_reduce_backlog on
> TC_H_ROOT") break the loop only when parent TC_H_ROOT is reached. However,
> qdisc_lookup_rcu() will return the same qdisc when input an ingress qdisc
> with major 'ffff'. If the parent TC_H_INGRESS is reached, also break the
> loop.
>
> Fixes: 2e95c4384438 ("net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT")
> Signed-off-by: Wang Liang <wangliang74@...wei.com>
> ---
>  net/sched/sch_api.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index 1e058b46d3e1..b4d6fe6b6812 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -784,7 +784,7 @@ void qdisc_tree_reduce_backlog(struct Qdisc *sch, int n, int len)
>         drops = max_t(int, n, 0);
>         rcu_read_lock();
>         while ((parentid = sch->parent)) {
> -               if (parentid == TC_H_ROOT)
> +               if (parentid == TC_H_ROOT || parentid == TC_H_INGRESS)
>                         break;
>
>                 if (sch->flags & TCQ_F_NOPARENT)
> --
> 2.34.1
>