netdev - Re: sch_qfq: race conditon on qfq_aggregate (net/sched/sch

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-next>] [day] [month] [year] [list]

Message-ID: <CAM0EoMn+UiSmpH=iBeevpUN5N8TW+2GSEmyk6vA2MWOKgsRjBA@mail.gmail.com>
Date: Sun, 29 Jun 2025 10:28:12 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Xiang Mei <xmei5@....edu>
Cc: security@...nel.org, 
	Linux Kernel Network Developers <netdev@...r.kernel.org>, Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: sch_qfq: race conditon on qfq_aggregate (net/sched/sch_qfq.c)

On Sun, Jun 29, 2025 at 3:13 AM Xiang Mei <xmei5@....edu> wrote:
>
> Linux Kernel Security Team,
>
> We are writing to bring to your attention a race condition vulnerability in net/sched/sch_qfq.c.
>
> In function qfq_delete_class, the line `qfq_destroy_class(sch, cl);` is outside the protection of ` sch_tree_lock`, so any operation on agg could lead to a race condition vulnerability. For example, we can get a UAF by racing it with qfq_change_agg in qfq_enqueue.
>
> We verified it on v6.6.94 and exploited it in kernelCTF cos-109-17800.519.32.
> A temporal fix could be
> ```c
> @@ -558,10 +562,9 @@ static int qfq_delete_class(struct Qdisc *sch, unsigned long arg,
>
>  qdisc_purge_queue(cl->qdisc);
>  qdisc_class_hash_remove(&q->clhash, &cl->common);
> -
> +        qfq_destroy_class(sch, cl);
>  sch_tree_unlock(sch);
>
> -       qfq_destroy_class(sch, cl);
>  return 0;
>  }
> ```
>
> But this only avoids the exploitation. There are other places to exploit the vulnerability with a General Protection (usually null-deref). We found two places that can crash the kernel:
>
> 1. When modifying an existing class in  qfq_change_class, the reads of cl->agg->weight or cl->agg->lmax could lead to GPs.
> 2. Reads of agg content in qfq_dump_class could lead to GPs.
>
> These reads of the agg structure may require `RCU` or `lock` to protect.
>
> Looking forward to hearing from you and discussing the patching.
>


Please partake in the discussion to fix this, your other issue and
others on the netdev list, start with this thread:
https://lore.kernel.org/netdev/aF847kk6H+kr5kIV@pop-os.localdomain/

cheers,
jamal


> Thanks,
> Xiang Mei