CVE-2025-39759
Last modified
CVE-2025-39759 is a high-severity vulnerability rated 7/10 on the CVSS scale. In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix race between quota disable and quota rescan ioctl There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree. This happens as follows: 1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan(); 2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A); 3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock; 4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free. Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled.. EPSS estimates a 0.11% chance of exploitation in the next 30 days.
Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix race between quota disable and quota rescan ioctl There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree. This happens as follows: 1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan(); 2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A); 3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock; 4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free. Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled.
Metrics
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness Enumeration
Affected Software
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux Kernel | >= 3.12, < 6.1.149 |
| Linux | Linux Kernel | >= 6.2, < 6.6.103 |
| Linux | Linux Kernel | >= 6.7, < 6.12.44 |
| Linux | Linux Kernel | >= 6.13, < 6.15.11 |
| Linux | Linux Kernel | >= 6.16, < 6.16.2 |
| Debian | Debian Linux | 11.0 |
References
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.htmlMailing List, Third Party Advisory
Timeline
- Published
- Last Modified
- Status
- Modified
Frequently Asked Questions
What is CVE-2025-39759?
How severe is CVE-2025-39759?
How do I fix CVE-2025-39759?
Are you affected by CVE-2025-39759?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
