In the Linux kernel, the following vulnerability has been resolved: nilfs2: Fix potential block overflow that cause system hang When a user executes the FITRIM command, an underflow can occur when calculating nblocks if endblock is too small. Since nblocks is of type sectort, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function _blkdevissuediscard() taking an excessively long time to process the bio chain, and the nssegctorsem lock remains held for a long period. This prevents other tasks from acquiring the nssegctorsem lock, resulting in the hang reported by syzbot in [1]. If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang. 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 taskflags:0x200040 flags:0x00080000 Call Trace: rwbasewritelock+0x3dd/0x750 kernel/locking/rwbasert.c:272 nilfstransactionlock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfssegctorthreadconstruct fs/nilfs2/segment.c:2569 [inline] nilfssegctorthread+0x6ec/0xe00 fs/nilfs2/segment.c:2684 [ryusuke: corrected part of the commit message about the consequences]