fs/f2fs/file.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
In my test case, concurrent calls to f2fs shutdown report the following
stack trace:
Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI
CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85
Call Trace:
<TASK>
? show_regs+0x8b/0xa0
? __die_body+0x26/0xa0
? die_addr+0x54/0x90
? exc_general_protection+0x24b/0x5c0
? asm_exc_general_protection+0x26/0x30
? kthread_stop+0x46/0x390
f2fs_stop_gc_thread+0x6c/0x110
f2fs_do_shutdown+0x309/0x3a0
f2fs_ioc_shutdown+0x150/0x1c0
__f2fs_ioctl+0xffd/0x2ac0
f2fs_ioctl+0x76/0xe0
vfs_ioctl+0x23/0x60
__x64_sys_ioctl+0xce/0xf0
x64_sys_call+0x2b1b/0x4540
do_syscall_64+0xa7/0x240
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The root cause is a race condition in f2fs_stop_gc_thread() called from
different f2fs shutdown paths:
[CPU0] [CPU1]
---------------------- -----------------------
f2fs_stop_gc_thread f2fs_stop_gc_thread
gc_th = sbi->gc_thread
gc_th = sbi->gc_thread
kfree(gc_th)
sbi->gc_thread = NULL
< gc_th != NULL >
kthread_stop(gc_th->f2fs_gc_task) //UAF
The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in
f2fs_stop_gc_thread()") attempted to fix this issue by using a read
semaphore to prevent races between shutdown and remount threads, but
it fails to prevent all race conditions.
Fix it by converting to write lock of s_umount in f2fs_do_shutdown().
Fixes: 7950e9ac638e ("f2fs: stop gc/discard thread after fs shutdown")
Signed-off-by: Long Li <leo.lilong@huawei.com>
---
fs/f2fs/file.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 75a8b22da664..703cfccc6b7e 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -2365,9 +2365,12 @@ int f2fs_do_shutdown(struct f2fs_sb_info *sbi, unsigned int flag,
if (readonly)
goto out;
- /* grab sb->s_umount to avoid racing w/ remount() */
+ /*
+ * grab sb->s_umount to avoid racing w/ remount() and other shutdown
+ * paths.
+ */
if (need_lock)
- down_read(&sbi->sb->s_umount);
+ down_write(&sbi->sb->s_umount);
f2fs_stop_gc_thread(sbi);
f2fs_stop_discard_thread(sbi);
@@ -2376,7 +2379,7 @@ int f2fs_do_shutdown(struct f2fs_sb_info *sbi, unsigned int flag,
clear_opt(sbi, DISCARD);
if (need_lock)
- up_read(&sbi->sb->s_umount);
+ up_write(&sbi->sb->s_umount);
f2fs_update_time(sbi, REQ_TIME);
out:
--
2.39.2On 2024/11/4 10:05, Long Li wrote:
> In my test case, concurrent calls to f2fs shutdown report the following
> stack trace:
>
> Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI
> CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85
> Call Trace:
> <TASK>
> ? show_regs+0x8b/0xa0
> ? __die_body+0x26/0xa0
> ? die_addr+0x54/0x90
> ? exc_general_protection+0x24b/0x5c0
> ? asm_exc_general_protection+0x26/0x30
> ? kthread_stop+0x46/0x390
> f2fs_stop_gc_thread+0x6c/0x110
> f2fs_do_shutdown+0x309/0x3a0
> f2fs_ioc_shutdown+0x150/0x1c0
> __f2fs_ioctl+0xffd/0x2ac0
> f2fs_ioctl+0x76/0xe0
> vfs_ioctl+0x23/0x60
> __x64_sys_ioctl+0xce/0xf0
> x64_sys_call+0x2b1b/0x4540
> do_syscall_64+0xa7/0x240
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> The root cause is a race condition in f2fs_stop_gc_thread() called from
> different f2fs shutdown paths:
>
> [CPU0] [CPU1]
> ---------------------- -----------------------
> f2fs_stop_gc_thread f2fs_stop_gc_thread
> gc_th = sbi->gc_thread
> gc_th = sbi->gc_thread
> kfree(gc_th)
> sbi->gc_thread = NULL
> < gc_th != NULL >
> kthread_stop(gc_th->f2fs_gc_task) //UAF
>
> The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in
> f2fs_stop_gc_thread()") attempted to fix this issue by using a read
> semaphore to prevent races between shutdown and remount threads, but
> it fails to prevent all race conditions.
>
> Fix it by converting to write lock of s_umount in f2fs_do_shutdown().
>
> Fixes: 7950e9ac638e ("f2fs: stop gc/discard thread after fs shutdown")
> Signed-off-by: Long Li <leo.lilong@huawei.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Thanks,
© 2016 - 2024 Red Hat, Inc.