CVE-2024-47689
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-47689
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-47689.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-47689
- Downstream
- Related
- Published
- 2024-10-21T11:53:29Z
- Modified
- 2025-10-09T19:02:00.794370Z
- Summary
- f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to don't set SBRDONLY in f2fshandlecriticalerror()
syzbot reports a f2fs bug as below:
------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcusyncdtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroysuperwork RIP: 0010:rcusyncdtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpufreerwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroysuperwork+0xec/0x130 fs/super.c:282 processonework kernel/workqueue.c:3231 [inline] processscheduledworks+0xa2c/0x1830 kernel/workqueue.c:3312 workerthread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244
As Christian Brauner pointed out [1]: the root cause is f2fs sets SBRDONLY flag in internal function, rather than setting the flag covered w/ sb->sumount semaphore via remount procedure, then below race condition causes this bug:
- freezesuper()
- sbwaitwrite(sb, SBFREEZEWRITE)
- sbwaitwrite(sb, SBFREEZEPAGEFAULT)
- sbwaitwrite(sb, SBFREEZEFS)
- f2fshandlecritical
- sb->sflags |= SBRDONLY
- thawsuper
- thawsuperlocked
- sbrdonly() is true, so it skips sbfreezeunlock(sb, SBFREEZE
- deactivatelockedsuper
Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CPERRORFLAG flag which indicates filesystem is stopped - record errors to superblock - set SBRDONLY falg Once we set CPERRORFLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SBRDONLY flag, let's remove the logic and keep in line w/ ext4 [3].
[1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz
- freezesuper()
- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/1f63f405c1a1a64b9c310388aad7055fb86b245c
- https://git.kernel.org/stable/c/649ec8b30df113042588bd3d3cd4e98bcb1091e0
- https://git.kernel.org/stable/c/930c6ab93492c4b15436524e704950b364b2930c
- https://git.kernel.org/stable/c/de43021c72993877a8f86f9fddfa0687609da5a4
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedb62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5Fixed649ec8b30df113042588bd3d3cd4e98bcb1091e0
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedb62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5Fixedde43021c72993877a8f86f9fddfa0687609da5a4
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedb62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5Fixed1f63f405c1a1a64b9c310388aad7055fb86b245c
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducedb62e71be2110d8b52bf5faf3c3ed7ca1a0c113a5Fixed930c6ab93492c4b15436524e704950b364b2930c
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduceded1d478bf838820201f3fb67a1748fdf15954ea4