[SRU][J][PATCH 0/2] CVE-2025-38477

[Tim Whisonant]

SRU Justification:

[Impact]

net/sched: sch_qfq: Fix race condition on qfq_aggregate

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.

net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class

might_sleep could be trigger in the atomic context in qfq_delete_class.

qfq_destroy_class was moved into atomic context locked
by sch_tree_lock to avoid a race condition bug on
qfq_aggregate. However, might_sleep could be triggered by
qfq_destroy_class, which introduced sleeping in atomic context (path:
qfq_destroy_class->qdisc_put->__qdisc_destroy->lockdep_unregister_key
->might_sleep).

Considering the race is on the qfq_aggregate objects, keeping
qfq_rm_from_agg in the lock but moving the left part out can solve
this issue.

[Fix]

Jammy: cherry picked from upstream

[Test Plan]

Compile and boot tested.

[Where problems could occur]

The changes occur in the Quick Fair Queueing Plus network
scheduling code. They implement locking for the QFQ class
data structure to address null pointer dereference and
use-after-free scenarios. Issues may arise when using this
queueing discipline.

[Notes]

The second patch cf074eca0065 ("net/sched: sch_qfq: Avoid triggering
might_sleep in atomic contextin qfq_delete_class") fixes a bug
introduced by the first patch.

Xiang Mei (2):
  net/sched: sch_qfq: Fix race condition on qfq_aggregate
  net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in
    qfq_delete_class

 net/sched/sch_qfq.c | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

-- 
2.43.0