netdev - Re: [PATCH v1] net/sched: sch_qfq: Fix race condition on qfq

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

Message-ID: <aGxgzS2dZo8fKUw5@xps>
Date: Mon, 7 Jul 2025 17:05:33 -0700
From: Xiang Mei <xmei5@....edu>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: netdev@...r.kernel.org, gregkh@...uxfoundation.org, jhs@...atatu.com,
	jiri@...nulli.us, security@...nel.org
Subject: Re: [PATCH v1] net/sched: sch_qfq: Fix race condition on
 qfq_aggregate

On Mon, Jul 07, 2025 at 11:03:50AM -0700, Cong Wang wrote:
> On Sat, Jul 05, 2025 at 03:39:58PM -0700, Xiang Mei wrote:
> > A race condition can occur when 'agg' is modified in qfq_change_agg
> > (called during qfq_enqueue) while other threads access it
> > concurrently. For example, qfq_dump_class may trigger a NULL
> > dereference, and qfq_delete_class may cause a use-after-free.
> > 
> > This patch addresses the issue by:
> > 
> > 1. Moved qfq_destroy_class into the critical section.
> > 
> > 2. Added sch_tree_lock protection to qfq_dump_class and
> > qfq_dump_class_stats.
> > 
> > Signed-off-by: Xiang Mei <xmei5@....edu>
> 
> Although holding sch_tree_lock() for control path is generally not
> elegant, this is clearly not your fault, the current code is already so.
> Converting to RCU requires more efforts, so it should be deferred to
> long term (net-next).
> 
> So as a bug fix, this patch is okay.

Appreciate your code review and guides for the recent two qfq patches.
I'll try to provide a RCU implementation on RCU after I triage other found 
 bugs.

> 
> Reviewed-by: Cong Wang <xiyou.wangcong@...il.com>
> 
> (I assume you tested it with all tdc selftests.)

The patched version passed the tc-testing and my pocs can't trigger the 
bug after patching.

> 
> Thanks!

I have two more questions:

1) Is the patch provider the person who usually adds the "Reported-by" tag?

2) Am I allowed to request a CVE number for this race condition bug?

Triggering this race condition requires "unprivileged user namespaces"
(net_admin) and the bug can lead to privilege escaping 
(refcnt issue -> UAF).

Thanks,
Xiang