In the Linux kernel, the following vulnerability has been resolved: quota: Fix race of dquot_scan_active() with quota deactivation dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_rele…

Overview

In the Linux kernel, the following vulnerability has been resolved:

quota: Fix race of dquot_scan_active() with quota deactivation

dquot_scan_active() can race with quota deactivation in quota_release_workfn() like:

CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set / spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { / finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count));

The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() 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

• linux_kernel >= 4.19.297, < 4.20
• linux_kernel >= 5.4.259, < 5.5
• linux_kernel >= 5.10.199, < 5.10.258
• linux_kernel >= 5.15.136, < 5.15.209
• linux_kernel >= 6.1.59, < 6.1.175
• linux_kernel >= 6.5.8, < 6.6
• linux_kernel >= 6.6.1, < 6.6.141
• linux_kernel >= 6.7, < 6.12.91
• linux_kernel >= 6.13, < 6.18.33
• linux_kernel >= 6.19, < 7.0.10
• linux_kernel = 6.6

Remediation

Upgrade past the affected range:

• linux_kernel 7.0.10