* UBSAN: shift-out-of-bounds in ext4_fill_super
@ 2020-12-09 7:33 syzbot
2020-12-10 2:36 ` Theodore Y. Ts'o
0 siblings, 1 reply; 10+ messages in thread
From: syzbot @ 2020-12-09 7:33 UTC (permalink / raw)
To: adilger.kernel, clang-built-linux, linux-ext4, linux-kernel,
natechancellor, ndesaulniers, syzkaller-bugs, tytso
Hello,
syzbot found the following issue on:
HEAD commit: 15ac8fdb Add linux-next specific files for 20201207
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1125c923500000
kernel config: https://syzkaller.appspot.com/x/.config?x=3696b8138207d24d
dashboard link: https://syzkaller.appspot.com/bug?extid=345b75652b1d24227443
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=151bf86b500000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=139212cb500000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+345b75652b1d24227443@syzkaller.appspotmail.com
loop0: detected capacity change from 4 to 0
================================================================================
UBSAN: shift-out-of-bounds in fs/ext4/super.c:4190:25
shift exponent 589825 is too large for 32-bit type 'int'
CPU: 1 PID: 8498 Comm: syz-executor023 Not tainted 5.10.0-rc6-next-20201207-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:120
ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
__ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
ext4_fill_super.cold+0x154/0x3ce fs/ext4/super.c:4190
mount_bdev+0x34d/0x410 fs/super.c:1366
legacy_get_tree+0x105/0x220 fs/fs_context.c:592
vfs_get_tree+0x89/0x2f0 fs/super.c:1496
do_new_mount fs/namespace.c:2896 [inline]
path_mount+0x12ae/0x1e70 fs/namespace.c:3227
do_mount fs/namespace.c:3240 [inline]
__do_sys_mount fs/namespace.c:3448 [inline]
__se_sys_mount fs/namespace.c:3425 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3425
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d6a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:00007ffc2d215018 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffc2d215070 RCX: 0000000000446d6a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffc2d215030
RBP: 00007ffc2d215030 R08: 00007ffc2d215070 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000001
R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003
================================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-09 7:33 UBSAN: shift-out-of-bounds in ext4_fill_super syzbot
@ 2020-12-10 2:36 ` Theodore Y. Ts'o
2020-12-10 3:50 ` syzbot
0 siblings, 1 reply; 10+ messages in thread
From: Theodore Y. Ts'o @ 2020-12-10 2:36 UTC (permalink / raw)
To: syzbot
Cc: adilger.kernel, clang-built-linux, linux-ext4, linux-kernel,
natechancellor, ndesaulniers, syzkaller-bugs
On Tue, Dec 08, 2020 at 11:33:11PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 15ac8fdb Add linux-next specific files for 20201207
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1125c923500000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3696b8138207d24d
> dashboard link: https://syzkaller.appspot.com/bug?extid=345b75652b1d24227443
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=151bf86b500000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=139212cb500000
#syz test git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git e360ba58d067a30a4e3e7d55ebdd919885a058d6
From 3d3bc303a8a8f7123cf486f49fa9060116fa1465 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Wed, 9 Dec 2020 15:59:11 -0500
Subject: [PATCH] ext4: check for invalid block size early when mounting a file
system
Check for valid block size directly by validating s_log_block_size; we
were doing this in two places. First, by calculating blocksize via
BLOCK_SIZE << s_log_block_size, and then checking that the blocksize
was valid. And then secondly, by checking s_log_block_size directly.
The first check is not reliable, and can trigger an UBSAN warning if
s_log_block_size on a maliciously corrupted superblock is greater than
22. This is harmless, since the second test will correctly reject the
maliciously fuzzed file system, but to make syzbot shut up, and
because the two checks are duplicative in any case, delete the
blocksize check, and move the s_log_block_size earlier in
ext4_fill_super().
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: syzbot+345b75652b1d24227443@syzkaller.appspotmail.com
---
fs/ext4/super.c | 40 ++++++++++++++++------------------------
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index f86220a8df50..4a16bbf0432c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4202,18 +4202,25 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
*/
sbi->s_li_wait_mult = EXT4_DEF_LI_WAIT_MULT;
- blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);
-
- if (blocksize == PAGE_SIZE)
- set_opt(sb, DIOREAD_NOLOCK);
-
- if (blocksize < EXT4_MIN_BLOCK_SIZE ||
- blocksize > EXT4_MAX_BLOCK_SIZE) {
+ if (le32_to_cpu(es->s_log_block_size) >
+ (EXT4_MAX_BLOCK_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
ext4_msg(sb, KERN_ERR,
- "Unsupported filesystem blocksize %d (%d log_block_size)",
- blocksize, le32_to_cpu(es->s_log_block_size));
+ "Invalid log block size: %u",
+ le32_to_cpu(es->s_log_block_size));
goto failed_mount;
}
+ if (le32_to_cpu(es->s_log_cluster_size) >
+ (EXT4_MAX_CLUSTER_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
+ ext4_msg(sb, KERN_ERR,
+ "Invalid log cluster size: %u",
+ le32_to_cpu(es->s_log_cluster_size));
+ goto failed_mount;
+ }
+
+ blocksize = EXT4_MIN_BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);
+
+ if (blocksize == PAGE_SIZE)
+ set_opt(sb, DIOREAD_NOLOCK);
if (le32_to_cpu(es->s_rev_level) == EXT4_GOOD_OLD_REV) {
sbi->s_inode_size = EXT4_GOOD_OLD_INODE_SIZE;
@@ -4432,21 +4439,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
if (!ext4_feature_set_ok(sb, (sb_rdonly(sb))))
goto failed_mount;
- if (le32_to_cpu(es->s_log_block_size) >
- (EXT4_MAX_BLOCK_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
- ext4_msg(sb, KERN_ERR,
- "Invalid log block size: %u",
- le32_to_cpu(es->s_log_block_size));
- goto failed_mount;
- }
- if (le32_to_cpu(es->s_log_cluster_size) >
- (EXT4_MAX_CLUSTER_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
- ext4_msg(sb, KERN_ERR,
- "Invalid log cluster size: %u",
- le32_to_cpu(es->s_log_cluster_size));
- goto failed_mount;
- }
-
if (le16_to_cpu(sbi->s_es->s_reserved_gdt_blocks) > (blocksize / 4)) {
ext4_msg(sb, KERN_ERR,
"Number of reserved GDT blocks insanely large: %d",
--
2.28.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-10 2:36 ` Theodore Y. Ts'o
@ 2020-12-10 3:50 ` syzbot
2020-12-10 8:09 ` Dmitry Vyukov
0 siblings, 1 reply; 10+ messages in thread
From: syzbot @ 2020-12-10 3:50 UTC (permalink / raw)
To: adilger.kernel, clang-built-linux, linux-ext4, linux-kernel,
natechancellor, ndesaulniers, syzkaller-bugs, tytso
Hello,
syzbot tried to test the proposed patch but the build/boot failed:
failed to checkout kernel repo git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git on commit e360ba58d067a30a4e3e7d55ebdd919885a058d6: failed to run ["git" "fetch" "--tags" "d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8"]: exit status 1
From git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
* [new branch] bisect-test-ext4-035 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/bisect-test-ext4-035
* [new branch] bisect-test-generic-307 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/bisect-test-generic-307
* [new branch] dev -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/dev
* [new branch] ext4-3.18 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-3.18
* [new branch] ext4-4.1 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.1
* [new branch] ext4-4.4 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.4
* [new branch] ext4-4.9 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.9
* [new branch] ext4-dax -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-dax
* [new branch] ext4-tools -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-tools
* [new branch] fix-bz-206443 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/fix-bz-206443
* [new branch] for-stable -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/for-stable
* [new branch] fsverity -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/fsverity
* [new branch] lazy_journal -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/lazy_journal
* [new branch] master -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/master
* [new branch] origin -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/origin
* [new branch] pu -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/pu
* [new branch] test -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/test
* [new tag] ext4-for-linus-5.8-rc1-2 -> ext4-for-linus-5.8-rc1-2
! [rejected] ext4_for_linus -> ext4_for_linus (would clobber existing tag)
* [new tag] ext4_for_linus_bugfixes -> ext4_for_linus_bugfixes
* [new tag] ext4_for_linus_cleanups -> ext4_for_linus_cleanups
* [new tag] ext4_for_linus_fixes -> ext4_for_linus_fixes
* [new tag] ext4_for_linus_fixes2 -> ext4_for_linus_fixes2
Tested on:
commit: [unknown
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git e360ba58d067a30a4e3e7d55ebdd919885a058d6
dashboard link: https://syzkaller.appspot.com/bug?extid=345b75652b1d24227443
compiler: gcc (GCC) 10.1.0-syz 20200507
patch: https://syzkaller.appspot.com/x/patch.diff?x=1499c287500000
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-10 3:50 ` syzbot
@ 2020-12-10 8:09 ` Dmitry Vyukov
2020-12-10 13:56 ` Dmitry Vyukov
2020-12-10 18:28 ` Theodore Y. Ts'o
0 siblings, 2 replies; 10+ messages in thread
From: Dmitry Vyukov @ 2020-12-10 8:09 UTC (permalink / raw)
To: syzbot
Cc: Andreas Dilger, clang-built-linux, linux-ext4, LKML,
Nathan Chancellor, Nick Desaulniers, syzkaller-bugs,
Theodore Ts'o
On Thu, Dec 10, 2020 at 4:50 AM syzbot
<syzbot+345b75652b1d24227443@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot tried to test the proposed patch but the build/boot failed:
>
> failed to checkout kernel repo git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git on commit e360ba58d067a30a4e3e7d55ebdd919885a058d6: failed to run ["git" "fetch" "--tags" "d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8"]: exit status 1
> From git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> * [new branch] bisect-test-ext4-035 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/bisect-test-ext4-035
> * [new branch] bisect-test-generic-307 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/bisect-test-generic-307
> * [new branch] dev -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/dev
> * [new branch] ext4-3.18 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-3.18
> * [new branch] ext4-4.1 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.1
> * [new branch] ext4-4.4 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.4
> * [new branch] ext4-4.9 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.9
> * [new branch] ext4-dax -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-dax
> * [new branch] ext4-tools -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-tools
> * [new branch] fix-bz-206443 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/fix-bz-206443
> * [new branch] for-stable -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/for-stable
> * [new branch] fsverity -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/fsverity
> * [new branch] lazy_journal -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/lazy_journal
> * [new branch] master -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/master
> * [new branch] origin -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/origin
> * [new branch] pu -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/pu
> * [new branch] test -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/test
> * [new tag] ext4-for-linus-5.8-rc1-2 -> ext4-for-linus-5.8-rc1-2
> ! [rejected] ext4_for_linus -> ext4_for_linus (would clobber existing tag)
Interesting. First time I see this. Should syzkaller use 'git fetch
--tags --force"?...
StackOverflow suggests it should help:
https://stackoverflow.com/questions/58031165/how-to-get-rid-of-would-clobber-existing-tag
> * [new tag] ext4_for_linus_bugfixes -> ext4_for_linus_bugfixes
> * [new tag] ext4_for_linus_cleanups -> ext4_for_linus_cleanups
> * [new tag] ext4_for_linus_fixes -> ext4_for_linus_fixes
> * [new tag] ext4_for_linus_fixes2 -> ext4_for_linus_fixes2
>
>
>
> Tested on:
>
> commit: [unknown
> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git e360ba58d067a30a4e3e7d55ebdd919885a058d6
> dashboard link: https://syzkaller.appspot.com/bug?extid=345b75652b1d24227443
> compiler: gcc (GCC) 10.1.0-syz 20200507
> patch: https://syzkaller.appspot.com/x/patch.diff?x=1499c287500000
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-10 8:09 ` Dmitry Vyukov
@ 2020-12-10 13:56 ` Dmitry Vyukov
2020-12-10 19:24 ` syzbot
2020-12-10 18:28 ` Theodore Y. Ts'o
1 sibling, 1 reply; 10+ messages in thread
From: Dmitry Vyukov @ 2020-12-10 13:56 UTC (permalink / raw)
To: syzbot
Cc: Andreas Dilger, clang-built-linux, linux-ext4, LKML,
Nathan Chancellor, Nick Desaulniers, syzkaller-bugs,
Theodore Ts'o
[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]
On Thu, Dec 10, 2020 at 9:09 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Thu, Dec 10, 2020 at 4:50 AM syzbot
> <syzbot+345b75652b1d24227443@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot tried to test the proposed patch but the build/boot failed:
> >
> > failed to checkout kernel repo git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git on commit e360ba58d067a30a4e3e7d55ebdd919885a058d6: failed to run ["git" "fetch" "--tags" "d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8"]: exit status 1
> > From git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> > * [new branch] bisect-test-ext4-035 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/bisect-test-ext4-035
> > * [new branch] bisect-test-generic-307 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/bisect-test-generic-307
> > * [new branch] dev -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/dev
> > * [new branch] ext4-3.18 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-3.18
> > * [new branch] ext4-4.1 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.1
> > * [new branch] ext4-4.4 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.4
> > * [new branch] ext4-4.9 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-4.9
> > * [new branch] ext4-dax -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-dax
> > * [new branch] ext4-tools -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/ext4-tools
> > * [new branch] fix-bz-206443 -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/fix-bz-206443
> > * [new branch] for-stable -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/for-stable
> > * [new branch] fsverity -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/fsverity
> > * [new branch] lazy_journal -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/lazy_journal
> > * [new branch] master -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/master
> > * [new branch] origin -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/origin
> > * [new branch] pu -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/pu
> > * [new branch] test -> d06f7b29746c7f0a52f349ff7fbf2a3f22d27cf8/test
> > * [new tag] ext4-for-linus-5.8-rc1-2 -> ext4-for-linus-5.8-rc1-2
> > ! [rejected] ext4_for_linus -> ext4_for_linus (would clobber existing tag)
>
> Interesting. First time I see this. Should syzkaller use 'git fetch
> --tags --force"?...
> StackOverflow suggests it should help:
> https://stackoverflow.com/questions/58031165/how-to-get-rid-of-would-clobber-existing-tag
I've added --force to fetches:
https://github.com/google/syzkaller/commit/9a72bc3440b65a01187ba4277b49d6bd821079cd
and it should be deployed by now. Let's try again:
#syz test git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
e360ba58d067a30a4e3e7d55ebdd919885a058d6
[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 3292 bytes --]
From 3d3bc303a8a8f7123cf486f49fa9060116fa1465 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Wed, 9 Dec 2020 15:59:11 -0500
Subject: [PATCH] ext4: check for invalid block size early when mounting a file
system
Check for valid block size directly by validating s_log_block_size; we
were doing this in two places. First, by calculating blocksize via
BLOCK_SIZE << s_log_block_size, and then checking that the blocksize
was valid. And then secondly, by checking s_log_block_size directly.
The first check is not reliable, and can trigger an UBSAN warning if
s_log_block_size on a maliciously corrupted superblock is greater than
22. This is harmless, since the second test will correctly reject the
maliciously fuzzed file system, but to make syzbot shut up, and
because the two checks are duplicative in any case, delete the
blocksize check, and move the s_log_block_size earlier in
ext4_fill_super().
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: syzbot+345b75652b1d24227443@syzkaller.appspotmail.com
---
fs/ext4/super.c | 40 ++++++++++++++++------------------------
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index f86220a8df50..4a16bbf0432c 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4202,18 +4202,25 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
*/
sbi->s_li_wait_mult = EXT4_DEF_LI_WAIT_MULT;
- blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);
-
- if (blocksize == PAGE_SIZE)
- set_opt(sb, DIOREAD_NOLOCK);
-
- if (blocksize < EXT4_MIN_BLOCK_SIZE ||
- blocksize > EXT4_MAX_BLOCK_SIZE) {
+ if (le32_to_cpu(es->s_log_block_size) >
+ (EXT4_MAX_BLOCK_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
ext4_msg(sb, KERN_ERR,
- "Unsupported filesystem blocksize %d (%d log_block_size)",
- blocksize, le32_to_cpu(es->s_log_block_size));
+ "Invalid log block size: %u",
+ le32_to_cpu(es->s_log_block_size));
goto failed_mount;
}
+ if (le32_to_cpu(es->s_log_cluster_size) >
+ (EXT4_MAX_CLUSTER_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
+ ext4_msg(sb, KERN_ERR,
+ "Invalid log cluster size: %u",
+ le32_to_cpu(es->s_log_cluster_size));
+ goto failed_mount;
+ }
+
+ blocksize = EXT4_MIN_BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);
+
+ if (blocksize == PAGE_SIZE)
+ set_opt(sb, DIOREAD_NOLOCK);
if (le32_to_cpu(es->s_rev_level) == EXT4_GOOD_OLD_REV) {
sbi->s_inode_size = EXT4_GOOD_OLD_INODE_SIZE;
@@ -4432,21 +4439,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
if (!ext4_feature_set_ok(sb, (sb_rdonly(sb))))
goto failed_mount;
- if (le32_to_cpu(es->s_log_block_size) >
- (EXT4_MAX_BLOCK_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
- ext4_msg(sb, KERN_ERR,
- "Invalid log block size: %u",
- le32_to_cpu(es->s_log_block_size));
- goto failed_mount;
- }
- if (le32_to_cpu(es->s_log_cluster_size) >
- (EXT4_MAX_CLUSTER_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
- ext4_msg(sb, KERN_ERR,
- "Invalid log cluster size: %u",
- le32_to_cpu(es->s_log_cluster_size));
- goto failed_mount;
- }
-
if (le16_to_cpu(sbi->s_es->s_reserved_gdt_blocks) > (blocksize / 4)) {
ext4_msg(sb, KERN_ERR,
"Number of reserved GDT blocks insanely large: %d",
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-10 8:09 ` Dmitry Vyukov
2020-12-10 13:56 ` Dmitry Vyukov
@ 2020-12-10 18:28 ` Theodore Y. Ts'o
2020-12-14 14:37 ` Dmitry Vyukov
1 sibling, 1 reply; 10+ messages in thread
From: Theodore Y. Ts'o @ 2020-12-10 18:28 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Andreas Dilger, clang-built-linux, linux-ext4, LKML,
Nathan Chancellor, Nick Desaulniers, syzkaller-bugs
On Thu, Dec 10, 2020 at 09:09:51AM +0100, Dmitry Vyukov wrote:
> > * [new tag] ext4-for-linus-5.8-rc1-2 -> ext4-for-linus-5.8-rc1-2
> > ! [rejected] ext4_for_linus -> ext4_for_linus (would clobber existing tag)
>
> Interesting. First time I see this. Should syzkaller use 'git fetch
> --tags --force"?...
> StackOverflow suggests it should help:
> https://stackoverflow.com/questions/58031165/how-to-get-rid-of-would-clobber-existing-tag
Yeah, sorry, ext4_for_linus is a signed tag which is only used to
authenticate my pull request to Linus. After Linus accepts the pull,
the digital signature is going to be upstream, and so I end up
deleting and the reusing that tag for the next merge window.
I guess I could just start always using ext4_for_linus-<VERSION> and
just delete the tags once they have been accepted, to keep my list of
tags clean.
It's going to make everyone else's tags who pull from ext4.git messy,
though, with gobs of tags that probably won't be of use to them. It
does avoid the need to use git fetch --tags --force, and I guess
people are used to the need to GC tags with the linux-repo. So maybe
that's the right thing to do going forward.
- Ted
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-10 13:56 ` Dmitry Vyukov
@ 2020-12-10 19:24 ` syzbot
0 siblings, 0 replies; 10+ messages in thread
From: syzbot @ 2020-12-10 19:24 UTC (permalink / raw)
To: adilger.kernel, clang-built-linux, dvyukov, linux-ext4,
linux-kernel, natechancellor, ndesaulniers, syzkaller-bugs,
tytso
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: syzbot+345b75652b1d24227443@syzkaller.appspotmail.com
Tested on:
commit: e360ba58 ext4: fix a memory leak of ext4_free_data
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
kernel config: https://syzkaller.appspot.com/x/.config?x=fe9725f8845d9fe6
dashboard link: https://syzkaller.appspot.com/bug?extid=345b75652b1d24227443
compiler: gcc (GCC) 10.1.0-syz 20200507
patch: https://syzkaller.appspot.com/x/patch.diff?x=1166cf17500000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-10 18:28 ` Theodore Y. Ts'o
@ 2020-12-14 14:37 ` Dmitry Vyukov
2020-12-14 20:36 ` Theodore Y. Ts'o
0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Vyukov @ 2020-12-14 14:37 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: syzbot, Andreas Dilger, clang-built-linux, linux-ext4, LKML,
Nathan Chancellor, Nick Desaulniers, syzkaller-bugs
On Thu, Dec 10, 2020 at 7:28 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Thu, Dec 10, 2020 at 09:09:51AM +0100, Dmitry Vyukov wrote:
> > > * [new tag] ext4-for-linus-5.8-rc1-2 -> ext4-for-linus-5.8-rc1-2
> > > ! [rejected] ext4_for_linus -> ext4_for_linus (would clobber existing tag)
> >
> > Interesting. First time I see this. Should syzkaller use 'git fetch
> > --tags --force"?...
> > StackOverflow suggests it should help:
> > https://stackoverflow.com/questions/58031165/how-to-get-rid-of-would-clobber-existing-tag
>
> Yeah, sorry, ext4_for_linus is a signed tag which is only used to
> authenticate my pull request to Linus. After Linus accepts the pull,
> the digital signature is going to be upstream, and so I end up
> deleting and the reusing that tag for the next merge window.
>
> I guess I could just start always using ext4_for_linus-<VERSION> and
> just delete the tags once they have been accepted, to keep my list of
> tags clean.
>
> It's going to make everyone else's tags who pull from ext4.git messy,
> though, with gobs of tags that probably won't be of use to them. It
> does avoid the need to use git fetch --tags --force, and I guess
> people are used to the need to GC tags with the linux-repo. So maybe
> that's the right thing to do going forward.
Hi Ted,
syzbot is now prepared and won't fail next time, nor on other similar
trees. Which is good.
So it's really up to you.
Thanks
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-14 14:37 ` Dmitry Vyukov
@ 2020-12-14 20:36 ` Theodore Y. Ts'o
2020-12-15 10:09 ` Dmitry Vyukov
0 siblings, 1 reply; 10+ messages in thread
From: Theodore Y. Ts'o @ 2020-12-14 20:36 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: Andreas Dilger, LKML, Nathan Chancellor, Nick Desaulniers
(Dropping off-topic lists)
On Mon, Dec 14, 2020 at 03:37:37PM +0100, Dmitry Vyukov wrote:
> > It's going to make everyone else's tags who pull from ext4.git messy,
> > though, with gobs of tags that probably won't be of use to them. It
> > does avoid the need to use git fetch --tags --force, and I guess
> > people are used to the need to GC tags with the linux-repo.
(I had meant to say linux-next repo above.)
> syzbot is now prepared and won't fail next time, nor on other similar
> trees. Which is good.
> So it's really up to you.
I'm curious --- are you having to do anything special in terms of
deleting old tags to keep the size of the repo under control? Git
will keep a tag around indefinitely, so if you have huge numbers of
next-YYYYMMDD tags in your repo, the size will grow without bound.
Are you doing anything to automatically garbage collect tags to preven
this from being a problem?
(I am not pulling linux-next every day; only when I need to debug a
bug reported against the -next tree, so I just manually delete the
tags as necessary. So I'm curious what folks who are following
linux-next are doing, and whether they have something specific for
linux-next tags, or whether they have a more general solution.)
Cheers,
- Ted
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: shift-out-of-bounds in ext4_fill_super
2020-12-14 20:36 ` Theodore Y. Ts'o
@ 2020-12-15 10:09 ` Dmitry Vyukov
0 siblings, 0 replies; 10+ messages in thread
From: Dmitry Vyukov @ 2020-12-15 10:09 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Andreas Dilger, LKML, Nathan Chancellor, Nick Desaulniers
On Mon, Dec 14, 2020 at 9:36 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> (Dropping off-topic lists)
>
> On Mon, Dec 14, 2020 at 03:37:37PM +0100, Dmitry Vyukov wrote:
> > > It's going to make everyone else's tags who pull from ext4.git messy,
> > > though, with gobs of tags that probably won't be of use to them. It
> > > does avoid the need to use git fetch --tags --force, and I guess
> > > people are used to the need to GC tags with the linux-repo.
>
> (I had meant to say linux-next repo above.)
>
> > syzbot is now prepared and won't fail next time, nor on other similar
> > trees. Which is good.
> > So it's really up to you.
>
> I'm curious --- are you having to do anything special in terms of
> deleting old tags to keep the size of the repo under control? Git
> will keep a tag around indefinitely, so if you have huge numbers of
> next-YYYYMMDD tags in your repo, the size will grow without bound.
> Are you doing anything to automatically garbage collect tags to preven
> this from being a problem?
>
> (I am not pulling linux-next every day; only when I need to debug a
> bug reported against the -next tree, so I just manually delete the
> tags as necessary. So I'm curious what folks who are following
> linux-next are doing, and whether they have something specific for
> linux-next tags, or whether they have a more general solution.)
>
> Cheers,
>
> - Ted
syzbot does not do anything special here, it just polls/fetches always.
Here are sizes of checkouts that it has now, these also include
in-tree builds, that may explain larger differences. They don't look
too bad.
2.8G upstream-bpf-kasan-gce/kernel
3.1G upstream-bpf-next-kasan-gce/kernel
5.1G upstream-gce-leak/kernel
6.3G upstream-kasan-gce/kernel
6.3G upstream-kasan-gce-386/kernel
6.3G upstream-kasan-gce-root/kernel
6.3G upstream-kasan-gce-selinux-root/kernel
9.3G upstream-kasan-gce-smack-root/kernel
2.8G upstream-kmsan-gce/kernel
2.8G upstream-kmsan-gce-386/kernel
2.9G upstream-linux-next-kasan-gce-root/kernel
6.3G upstream-net-kasan-gce/kernel
2.7G upstream-net-this-kasan-gce/kernel
5.5G android-414-kasan-gce-root/kernel
6.5G android-44-kasan-gce/kernel
6.5G android-44-kasan-gce-386/kernel
6.0G android-49-kasan-gce/kernel
6.0G android-49-kasan-gce-386/kernel
6.1G android-49-kasan-gce-root/kernel
And the one is used for all patch testing on random trees is 5.2G, it has:
kernel$ git remote -v | wc -l
60
kernel$ git tag -l | wc -l
7544
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-12-15 10:10 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-09 7:33 UBSAN: shift-out-of-bounds in ext4_fill_super syzbot
2020-12-10 2:36 ` Theodore Y. Ts'o
2020-12-10 3:50 ` syzbot
2020-12-10 8:09 ` Dmitry Vyukov
2020-12-10 13:56 ` Dmitry Vyukov
2020-12-10 19:24 ` syzbot
2020-12-10 18:28 ` Theodore Y. Ts'o
2020-12-14 14:37 ` Dmitry Vyukov
2020-12-14 20:36 ` Theodore Y. Ts'o
2020-12-15 10:09 ` Dmitry Vyukov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.