This is a note to let you know that I've just added the patch titled
nilfs2: fix possible out-of-bounds segment allocation in resize ioctl
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
nilfs2-fix-possible-out-of-bounds-segment-allocation-in-resize-ioctl.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From fee5eaecca86afa544355569b831c1f90f334b85 Mon Sep 17 00:00:00 2001
From: Ryusuke Konishi <konishi.ryusuke@xxxxxxxxx>
Date: Wed, 24 May 2023 18:43:48 +0900
Subject: nilfs2: fix possible out-of-bounds segment allocation in resize ioctl
From: Ryusuke Konishi <konishi.ryusuke@xxxxxxxxx>
commit fee5eaecca86afa544355569b831c1f90f334b85 upstream.
Syzbot reports that in its stress test for resize ioctl, the log writing
function nilfs_segctor_do_construct hits a WARN_ON in
nilfs_segctor_truncate_segments().
It turned out that there is a problem with the current implementation of
the resize ioctl, which changes the writable range on the device (the
range of allocatable segments) at the end of the resize process.
This order is necessary for file system expansion to avoid corrupting the
superblock at trailing edge. However, in the case of a file system
shrink, if log writes occur after truncating out-of-bounds trailing
segments and before the resize is complete, segments may be allocated from
the truncated space.
The userspace resize tool was fine as it limits the range of allocatable
segments before performing the resize, but it can run into this issue if
the resize ioctl is called alone.
Fix this issue by changing nilfs_sufile_resize() to update the range of
allocatable segments immediately after successful truncation of segment
space in case of file system shrink.
Link: https://lkml.kernel.org/r/20230524094348.3784-1-konishi.ryusuke@xxxxxxxxx
Fixes: 4e33f9eab07e ("nilfs2: implement resize ioctl")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@xxxxxxxxx>
Reported-by: syzbot+33494cd0df2ec2931851@xxxxxxxxxxxxxxxxxxxxxxxxx
Closes: https://lkml.kernel.org/r/0000000000005434c405fbbafdc5@xxxxxxxxxx
Tested-by: Ryusuke Konishi <konishi.ryusuke@xxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
fs/nilfs2/sufile.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/fs/nilfs2/sufile.c
+++ b/fs/nilfs2/sufile.c
@@ -782,6 +782,15 @@ int nilfs_sufile_resize(struct inode *su
goto out_header;
sui->ncleansegs -= nsegs - newnsegs;
+
+ /*
+ * If the sufile is successfully truncated, immediately adjust
+ * the segment allocation space while locking the semaphore
+ * "mi_sem" so that nilfs_sufile_alloc() never allocates
+ * segments in the truncated space.
+ */
+ sui->allocmax = newnsegs - 1;
+ sui->allocmin = 0;
}
kaddr = kmap_atomic(header_bh->b_page);
Patches currently in stable-queue which might be from konishi.ryusuke@xxxxxxxxx are
queue-4.19/nilfs2-fix-incomplete-buffer-cleanup-in-nilfs_btnode_abort_change_key.patch
queue-4.19/nilfs2-fix-possible-out-of-bounds-segment-allocation-in-resize-ioctl.patch
