Re: [PATCH v1] net/sched: sch_qfq: Fix race condition on qfq_aggregate

[Xiang Mei <xmei5@asu.edu>]

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@asu.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@gmail.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