diff options
author | Theodore Ts'o <tytso@mit.edu> | 2023-04-29 00:06:28 -0400 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2023-05-13 18:02:46 -0400 |
commit | 5354b2af34064a4579be8bc0e2f15a7b70f14b5f (patch) | |
tree | 3773ab319b4d2d73fb10a769dca60c37f0f8f1b2 /scripts/gdb/linux/timerlist.py | |
parent | 949f95ff39bf188e594e7ecd8e29b82eb108f5bf (diff) |
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Diffstat (limited to 'scripts/gdb/linux/timerlist.py')
0 files changed, 0 insertions, 0 deletions