CVE-2026-53050: quota: Fix race of dquot_scan_active() with quota deactivation
In the Linux kernel, the following vulnerability has been resolved:
quota: Fix race of dquotscanactive() with quota deactivation
dquotscanactive() can race with quota deactivation in quotareleaseworkfn() like:
CPU0 (quotareleaseworkfn) CPU1 (dquotscanactive) ============================== ============================== spinlock(&dqlistlock); listreplaceinit( &releasingdquots, &rlshead); / dquot X on rlshead, dqcount == 0, DQACTIVEB still set / spinunlock(&dqlistlock); synchronizesrcu(&dquotsrcu); spinlock(&dqlistlock); listforeachentry(dquot, &inuselist, dqinuse) { / finds dquot X / dquotactive(X) -> true atomicinc(&X->dqcount); } spinunlock(&dqlistlock); spinlock(&dqlistlock); dquot = listfirstentry(&rlshead); WARNONONCE(atomicread(&dquot->dqcount));
The problem is not only a cosmetic one as under memory pressure the caller of dquotscanactive() can end up working on freed dquot.
Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it.
Affected Software
Remediation
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems running an affected Linux kernel or the listed Microsoft azl3 kernel are exposed when kernel quota handling is in use. Exploitation requires local access and low privileges; no user interaction is required.
What conditions are needed to trigger the race?
The race occurs between dquot_scan_active() and quota deactivation in quota_release_workfn(). Under memory pressure, the scanning path can operate on a dquot object after it has been freed.
Is there a patch available?
Yes. The issue has been resolved and patch references are provided for stable kernel trees.