linux-kernel - Re: UBSAN: shift-out-of-bounds in ext4_fill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACT4Y+Yz+zahS-7OjcYvn9a1RWsW4XJ7-_HWPcd4PR8mrMSajg@mail.gmail.com>
Date:   Tue, 15 Dec 2020 11:09:17 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Andreas Dilger <adilger.kernel@...ger.ca>,
        LKML <linux-kernel@...r.kernel.org>,
        Nathan Chancellor <natechancellor@...il.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: UBSAN: shift-out-of-bounds in ext4_fill_super

On Mon, Dec 14, 2020 at 9:36 PM Theodore Y. Ts'o <tytso@....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