Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-15 Thread Dmitry Vyukov 
On Mon, Dec 14, 2020 at 9:36 PM Theodore Y. Ts'o  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-MMDD 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

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-14 Thread Theodore Y. Ts'o 
(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-MMDD 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

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-14 Thread Dmitry Vyukov 
On Thu, Dec 10, 2020 at 7:28 PM Theodore Y. Ts'o  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- 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

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-10 Thread syzbot 
Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any 
issue:

Reported-and-tested-by: syzbot+345b75652b1d24227...@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=1166cf1750

Note: testing is done by a robot and is best-effort only.

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-10 Thread Theodore Y. Ts'o 
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- 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

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-10 Thread Dmitry Vyukov 
On Thu, Dec 10, 2020 at 9:09 AM Dmitry Vyukov  wrote:
>
> On Thu, Dec 10, 2020 at 4:50 AM syzbot
>  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


patch
Description: Binary data

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-10 Thread Dmitry Vyukov 
On Thu, Dec 10, 2020 at 4:50 AM syzbot
 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=1499c28750

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-09 Thread syzbot 
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=1499c28750

Re: UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-09 Thread Theodore Y. Ts'o 
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=1125c92350
> 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=151bf86b50
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=139212cb50

#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 
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 
Reported-by: syzbot+345b75652b1d24227...@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

UBSAN: shift-out-of-bounds in ext4_fill_super

2020-12-08 Thread syzbot 
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=1125c92350
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=151bf86b50
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=139212cb50

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+345b75652b1d24227...@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:7ffc2d215018 EFLAGS: 0206 ORIG_RAX: 00a5
RAX: ffda RBX: 7ffc2d215070 RCX: 00446d6a
RDX: 2000 RSI: 2100 RDI: 7ffc2d215030
RBP: 7ffc2d215030 R08: 7ffc2d215070 R09: 
R10:  R11: 0206 R12: 0001
R13: 0004 R14: 0003 R15: 0003



---
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 syzkal...@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