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

f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()

syzbot reports a f2fs bug as below:

------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+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 destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
destroy_super_work+0xec/0x130 fs/super.c:282
process_one_work kernel/workqueue.c:3231 [inline]
process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb->s_umount semaphore via remount procedure, then below
race condition causes this bug:

- freeze_super()
- sb_wait_write(sb, SB_FREEZE_WRITE)
- sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
- sb_wait_write(sb, SB_FREEZE_FS)
- f2fs_handle_critical_error
- sb->s_flags |= SB_RDONLY
- thaw_super
- thaw_super_locked
- sb_rdonly() is true, so it skips
sb_freeze_unlock(sb, SB_FREEZE_FS)
- deactivate_locked_super

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 CP_ERROR_FLAG flag which indicates filesystem is stopped
- record errors to superblock
- set SB_RDONLY falg
Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the
flag and stop any further updates on filesystem. So, it is safe to not
set SB_RDONLY 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
Published: 2024-10-21
Score: 5.3 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-7276-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7277-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7301-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7303-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7303-2 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7303-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7304-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7310-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7311-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7384-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-7384-2 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-7385-1 Linux kernel (IBM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7386-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7403-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7468-1 Linux kernel (Azure, N-Series) vulnerabilities
History

Wed, 23 Oct 2024 16:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Weaknesses CWE-362
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

 cvssV3_1

{'score': 5.3, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

Tue, 22 Oct 2024 01:30:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Mon, 21 Oct 2024 13:15:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Mon, 21 Oct 2024 12:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+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 destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) - f2fs_handle_critical_error - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super 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 CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY 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
Title f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T20:38:51.636Z

Reserved: 2024-09-30T16:00:12.941Z

Link: CVE-2024-47689

cve-icon Vulnrichment

Updated: 2024-10-21T13:06:15.254Z

cve-icon NVD

Status : Analyzed

Published: 2024-10-21T12:15:05.733

Modified: 2024-10-23T15:53:06.410

Link: CVE-2024-47689

cve-icon Redhat

Severity : Moderate

Publid Date: 2024-10-21T00:00:00Z

Links: CVE-2024-47689 - Bugzilla

cve-icon OpenCVE Enrichment

No data.

Weaknesses