CVE-2026-53050

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: Fix race of dquot_scan_active() with quota deactivation<br /> <br /> dquot_scan_active() can race with quota deactivation in<br /> quota_release_workfn() like:<br /> <br /> CPU0 (quota_release_workfn) CPU1 (dquot_scan_active)<br /> ============================== ==============================<br /> spin_lock(&amp;dq_list_lock);<br /> list_replace_init(<br /> &amp;releasing_dquots, &amp;rls_head);<br /> /* dquot X on rls_head,<br /> dq_count == 0,<br /> DQ_ACTIVE_B still set */<br /> spin_unlock(&amp;dq_list_lock);<br /> synchronize_srcu(&amp;dquot_srcu);<br /> spin_lock(&amp;dq_list_lock);<br /> list_for_each_entry(dquot,<br /> &amp;inuse_list, dq_inuse) {<br /> /* finds dquot X */<br /> dquot_active(X) -&gt; true<br /> atomic_inc(&amp;X-&gt;dq_count);<br /> }<br /> spin_unlock(&amp;dq_list_lock);<br /> spin_lock(&amp;dq_list_lock);<br /> dquot = list_first_entry(&amp;rls_head);<br /> WARN_ON_ONCE(atomic_read(&amp;dquot-&gt;dq_count));<br /> <br /> The problem is not only a cosmetic one as under memory pressure the<br /> caller of dquot_scan_active() can end up working on freed dquot.<br /> <br /> Fix the problem by making sure the dquot is removed from releasing list<br /> when we acquire a reference to it.