linux-kernel - Re: [PATCH v5] nilfs2: Fix potential block overflow that cause system hang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKFNMok7oYJmwYtEEOLZ4qYHAPzqq8uJnc3AgospWq6Q-DrpEA@mail.gmail.com>
Date: Thu, 18 Dec 2025 21:42:53 +0900
From: Ryusuke Konishi <konishi.ryusuke@...il.com>
To: Edward Adam Davis <eadavis@...com>
Cc: axboe@...nel.dk, kristian@...usen.dk, linux-kernel@...r.kernel.org, 
	linux-nilfs@...r.kernel.org, slava@...eyko.com, 
	syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH v5] nilfs2: Fix potential block overflow that cause system hang

On Thu, Dec 18, 2025 at 9:11 PM Edward Adam Davis  wrote:
>
> When a user executes the FITRIM command, an underflow can occur when
> calculating nblocks if end_block is too small. Since nblocks is of
> type sector_t, which is u64, a negative nblocks value will become a
> very large positive integer. This ultimately leads to the block layer
> function __blkdev_issue_discard() taking an excessively long time to
> process the bio chain, and the ns_segctor_sem lock remains held for a
> long period. This prevents other tasks from acquiring the ns_segctor_sem
> lock, resulting in the hang reported by syzbot in [1].
>
> If the ending block is too small, for example, smaller than first data
> block, this poses a risk of corrupting the filesystem's superblock.
> Exiting successfully and assign the discarded size (0 in this case)
> to range->len.
>
> Although the start and len values in the user input range are too small,
> a conservative strategy is adopted here to safely ignore them, which is
> equivalent to a no-op; it will not perform any trimming and will not
> throw an error.
>
> [1]
> task:segctord state:D stack:28968 pid:6093 tgid:6093  ppid:2 task_flags:0x200040 flags:0x00080000
> Call Trace:
>  rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272
>  nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357
>  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]
>  nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684
>
> Fixes: 82e11e857be3 ("nilfs2: add nilfs_sufile_trim_fs to trim clean segs")
> Reported-by: syzbot+7eedce5eb281acd832f0@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=7eedce5eb281acd832f0
> Signed-off-by: Edward Adam Davis <eadavis@...com>
> ---
> v4 -> v5: assign discarded size to range->len
> v3 -> v4: check end block and first data block
> v2 -> v3: change to segment end check and update comments
> v1 -> v2: continue do discard and comments
>
>  fs/nilfs2/sufile.c | 3 ++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/nilfs2/sufile.c b/fs/nilfs2/sufile.c
> index 83f93337c01b..eceedca02697 100644
> --- a/fs/nilfs2/sufile.c
> +++ b/fs/nilfs2/sufile.c
> @@ -1093,6 +1093,9 @@ int nilfs_sufile_trim_fs(struct inode *sufile, struct fstrim_range *range)
>         else
>                 end_block = start_block + len - 1;
>
> +       if (end_block < nilfs->ns_first_data_block)
> +               goto out;
> +
>         segnum = nilfs_get_segnum_of_block(nilfs, start_block);
>         segnum_end = nilfs_get_segnum_of_block(nilfs, end_block);
>
> @@ -1191,6 +1194,7 @@ int nilfs_sufile_trim_fs(struct inode *sufile, struct fstrim_range *range)
>  out_sem:
>         up_read(&NILFS_MDT(sufile)->mi_sem);
>
> +out:
>         range->len = ndiscarded << nilfs->ns_blocksize_bits;
>         return ret;
>  }
> --
> 2.43.0

Thanks Edward!

I'll send this v5 patch upstream once I've tested it.

Ryusuke Konishi