In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix shift-out-of-bounds due to too large exponent of block size

If field slogblocksize of superblock data is corrupted and too large, initnilfs() and loadnilfs() still can trigger a shift-out-of-bounds warning followed by a kernel panic (if paniconwarn is set):

shift exponent 38973 is too large for 32-bit type 'int' Call Trace: <TASK> dumpstacklvl+0xcd/0x134 ubsanepilogue+0xb/0x50 ubsanhandleshiftoutofbounds.cold.12+0x17b/0x1f5 initnilfs.cold.11+0x18/0x1d [nilfs2] nilfsmount+0x9b5/0x12b0 [nilfs2] ...

This fixes the issue by adding and using a new helper function for getting block size with sanity check.

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential UAF of struct nilfsscinfo in nilfssegctorthread()

The finalization of nilfssegctorthread() can race with nilfssegctorkillthread() which terminates that thread, potentially causing a use-after-free BUG as KASAN detected.

At the end of nilfssegctorthread(), it assigns NULL to "sctask" member of "struct nilfsscinfo" to indicate the thread has finished, and then notifies nilfssegctorkillthread() of this using waitqueue "scwaittask" on the struct nilfsscinfo.

However, here, immediately after the NULL assignment to "sctask", it is possible that nilfssegctorkillthread() will detect it and return to continue the deallocation, freeing the nilfsscinfo structure before the thread does the notification.

This fixes the issue by protecting the NULL assignment to "sctask" and its notification, with spinlock "scstatelock" of the struct nilfsscinfo. Since nilfssegctorkillthread() does a final check to see if "sctask" is NULL with "scstatelock" locked, this can eliminate the race.

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix shift-out-of-bounds/overflow in nilfssb2badoffset()

Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount time".

The first patch fixes a bug reported by syzbot, and the second one fixes the remaining bug of the same kind. Although they are triggered by the same super block data anomaly, I divided it into the above two because the details of the issues and how to fix it are different.

Both are required to eliminate the shift-out-of-bounds issues at mount time.

This patch (of 2):

If the block size exponent information written in an on-disk superblock is corrupted, nilfssb2badoffset helper function can trigger shift-out-of-bounds warning followed by a kernel panic (if paniconwarn is set):

shift exponent 38983 is too large for 64-bit type 'unsigned long long' Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:151 [inline] ubsanhandleshiftoutofbounds+0x33d/0x3b0 lib/ubsan.c:322 nilfssb2badoffset fs/nilfs2/thenilfs.c:449 [inline] nilfsloadsuperblock+0xdf5/0xe00 fs/nilfs2/thenilfs.c:523 initnilfs+0xb7/0x7d0 fs/nilfs2/thenilfs.c:577 nilfsfillsuper+0xb1/0x5d0 fs/nilfs2/super.c:1047 nilfsmount+0x613/0x9b0 fs/nilfs2/super.c:1317 ...

In addition, since nilfssb2badoffset() performs multiplication without considering the upper bound, the computation may overflow if the disk layout parameters are not normal.

This fixes these issues by inserting preliminary sanity checks for those parameters and by converting the comparison from one involving multiplication and left bit-shifting to one using division and right bit-shifting.