CVE-2025-23132High· 7.0▾ Twilight

f2fs: quota: fix to avoid warning in dquot_writeback_dquots()

In the Linux kernel, the following vulnerability has been resolved: f2fs: quota: fix to avoid warning in dquot_writeback_dquots() F2FS-fs (dm-59): checkpoint=enable has some unwritten data. ------------[ cut here ]------------ WARNING…

▾ Twilight zone — High severity, or a signal on a lesser flaw

Depth score39/ 100 · Low

impact 38.5 · likelihood 0.1 · exploitation 0

⚡ Agent-ready:Raw markdown ↗JSON ↗

Proof of concept

Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.

…

Published

Apr 16, 2025

Updated

Oct 21, 2026

CVSS

7.0

Vendor

Linux

Product

Linux

CWE

—

Depth score

39 · Low

EPSS

0.38% · p32

Platforms

—

Source

CVEORG

Vector

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

CISA SSVC

decided 2026-10-15

Exploitation: none
Automatable: no
Technical impact: total

Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the assigning CNA record, not NVD.

EPSS history

Exploit-prediction probability, daily snapshots since Oct 15.

0.3% → 0.4%▲ 0.1%

Timeline

Disclosure to exploitation, from the record and what we observed since indexing it.

4 events · 558 days

Apr 16, 2025Published
Disclosed via CVEORG
Oct 15, 2026EPSS first tracked
0.3%
Oct 21, 2026Record revised
Last analysed / modified upstream
Oct 26, 2026EPSS peak
0.3% → 0.4%

Linux #cve.org

Affected

Linux >= af033b2aa8a874fd5737fafe90d159136527b5b4 < 9ec535db9da76dafa05c89f8b58a0b1d7dddba1c
Linux >= af033b2aa8a874fd5737fafe90d159136527b5b4 < d7acf0a6c87aa282c86a36dbaa2f92fda88c5884
Linux >= af033b2aa8a874fd5737fafe90d159136527b5b4 < eb85c2410d6f581e957cd03a644ff6ddbe592af9
Linux 4.20

Full technical detail▾

Overview

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

f2fs: quota: fix to avoid warning in dquot_writeback_dquots()

F2FS-fs (dm-59): checkpoint=enable has some unwritten data.

------------[ cut here ]------------ WARNING: CPU: 6 PID: 8013 at fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308 pc : dquot_writeback_dquots+0x2fc/0x308 lr : f2fs_quota_sync+0xcc/0x1c4 Call trace: dquot_writeback_dquots+0x2fc/0x308 f2fs_quota_sync+0xcc/0x1c4 f2fs_write_checkpoint+0x3d4/0x9b0 f2fs_issue_checkpoint+0x1bc/0x2c0 f2fs_sync_fs+0x54/0x150 f2fs_do_sync_file+0x2f8/0x814 __f2fs_ioctl+0x1960/0x3244 f2fs_ioctl+0x54/0xe0 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x114

checkpoint and f2fs_remount may race as below, resulting triggering warning in dquot_writeback_dquots().

atomic write remount - do_remount - down_write(&sb->s_umount); - f2fs_remount

ioctl
f2fs_do_sync_file
f2fs_sync_fs
f2fs_write_checkpoint - block_operations
- locked = down_read_trylock(&sbi->sb->s_umount) : fail to lock due to the write lock was held by remount - up_write(&sb->s_umount);
- f2fs_quota_sync
- dquot_writeback_dquots
- WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)) : trigger warning because s_umount lock was unlocked by remount

If checkpoint comes from mount/umount/remount/freeze/quotactl, caller of checkpoint has already held s_umount lock, calling dquot_writeback_dquots() in the context should be safe.

So let's record task to sbi->umount_lock_holder, so that checkpoint can know whether the lock has held in the context or not by checking current w/ it.

In addition, in order to not misrepresent caller of checkpoint, we should not allow to trigger async checkpoint for those callers: mount/umount/remount/ freeze/quotactl.

Affected

Linux >= af033b2aa8a874fd5737fafe90d159136527b5b4 < 9ec535db9da76dafa05c89f8b58a0b1d7dddba1c
Linux >= af033b2aa8a874fd5737fafe90d159136527b5b4 < d7acf0a6c87aa282c86a36dbaa2f92fda88c5884
Linux >= af033b2aa8a874fd5737fafe90d159136527b5b4 < eb85c2410d6f581e957cd03a644ff6ddbe592af9
Linux 4.20

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

References

Related vulnerabilities

Connected by shared product, vendor, weakness, or advisory.

#cve.org

f2fs: quota: fix to avoid warning in dquot_writeback_dquots()

▾ Twilight zone — High severity, or a signal on a lesser flaw

Depth score39/ 100 · Low

impact 38.5 · likelihood 0.1 · exploitation 0

Overview

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

f2fs: quota: fix to avoid warning in dquot_writeback_dquots()

F2FS-fs (dm-59): checkpoint=enable has some unwritten data.

checkpoint and f2fs_remount may race as below, resulting triggering warning in dquot_writeback_dquots().

atomic write remount - do_remount - down_write(&sb->s_umount); - f2fs_remount

ioctl

f2fs_do_sync_file

f2fs_sync_fs

f2fs_write_checkpoint - block_operations

locked = down_read_trylock(&sbi->sb->s_umount) : fail to lock due to the write lock was held by remount - up_write(&sb->s_umount);
f2fs_quota_sync
dquot_writeback_dquots
WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)) : trigger warning because s_umount lock was unlocked by remount

If checkpoint comes from mount/umount/remount/freeze/quotactl, caller of checkpoint has already held s_umount lock, calling dquot_writeback_dquots() in the context should be safe.

So let's record task to sbi->umount_lock_holder, so that checkpoint can know whether the lock has held in the context or not by checking current w/ it.

In addition, in order to not misrepresent caller of checkpoint, we should not allow to trigger async checkpoint for those callers: mount/umount/remount/ freeze/quotactl.