On Mon, Nov 21, 2022 at 12:51:31AM +0900, Ryusuke Konishi wrote: > commit 8cccf05fe857a18ee26e20d11a8455a73ffd4efd upstream. > > If a nilfs2 filesystem is downgraded to read-only due to metadata > corruption on disk and is remounted read/write, or if emergency read-only > remount is performed, detaching a log writer and synchronizing the > filesystem can be done at the same time. > > In these cases, use-after-free of the log writer (hereinafter > nilfs->ns_writer) can happen as shown in the scenario below: > > Task1 Task2 > -------------------------------- ------------------------------ > nilfs_construct_segment > nilfs_segctor_sync > init_wait > init_waitqueue_entry > add_wait_queue > schedule > nilfs_remount (R/W remount case) > nilfs_attach_log_writer > nilfs_detach_log_writer > nilfs_segctor_destroy > kfree > finish_wait > _raw_spin_lock_irqsave > __raw_spin_lock_irqsave > do_raw_spin_lock > debug_spin_lock_before <-- use-after-free > > While Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1 > waked up, Task1 accesses nilfs->ns_writer which is already freed. This > scenario diagram is based on the Shigeru Yoshida's post [1]. > > This patch fixes the issue by not detaching nilfs->ns_writer on remount so > that this UAF race doesn't happen. Along with this change, this patch > also inserts a few necessary read-only checks with superblock instance > where only the ns_writer pointer was used to check if the filesystem is > read-only. > > Link: https://syzkaller.appspot.com/bug?id=79a4c002e960419ca173d55e863bd09e8112df8b > Link: https://lkml.kernel.org/r/20221103141759.1836312-1-syoshida@xxxxxxxxxx [1] > Link: https://lkml.kernel.org/r/20221104142959.28296-1-konishi.ryusuke@xxxxxxxxx > Signed-off-by: Ryusuke Konishi <konishi.ryusuke@xxxxxxxxx> > Reported-by: syzbot+f816fa82f8783f7a02bb@xxxxxxxxxxxxxxxxxxxxxxxxx > Reported-by: Shigeru Yoshida <syoshida@xxxxxxxxxx> > Tested-by: Ryusuke Konishi <konishi.ryusuke@xxxxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > --- > Please apply this patch to stable-4.14 instead of the patch that could > not be applied to it last time. > > A rejected hunk has been manually resolved without noticeable change, > and testing against that stable tree was fine. > Now queued up, thanks. greg k-h
