linux-kernel - Re: KASAN: use-after-free Write in detach_if

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CACT4Y+bRqQFNg-GL6Cd_gA6ZfJGz6Hb2Dhfjqp5fbvRWb+09Zg@mail.gmail.com>
Date:   Mon, 30 Oct 2017 18:40:16 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        syzbot 
        <bot+c0733f3aab92fc116dc1d10d8a25f5bf1f739eff@...kaller.appspotmail.com>,
        John Stultz <john.stultz@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>, sboyd@...eaurora.org,
        syzkaller-bugs@...glegroups.com, netdev <netdev@...r.kernel.org>,
        Jason Wang <jasowang@...hat.com>,
        David Miller <davem@...emloft.net>
Subject: Re: KASAN: use-after-free Write in detach_if_pending

On Mon, Oct 30, 2017 at 6:30 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Mon, 2017-10-30 at 18:06 +0100, Dmitry Vyukov wrote:
>
>> Yes, but hashes in random trees also don't tell much. A tree can be
>> rebased so the hash will be lost. It can be a tree unknown to the
>> system. Even if we find the commit by hash, in order to match it
>> against other trees we will have to use the title anyway (or are there
>> better options?), so using hashes becomes pointless.
>
> We do not send hashes on random trees, but official SHA1 in David Miller
> trees. They will be the same SHA1 in official Linus Torvalds tree.
>
> Really, you make our life more difficult by pretending that hashes are
> not the proper way.
>
> They are reasons we use Fixes: tags all over the places, they are unique
> in Linus tree.
>
> Since syzbot gives a SHA1 itself, it must be using a tree, right ?
>
> So a SHA1 that is guaranteed to enter the same tree is correct.
>
> Please fix your bot.

They don't necessary enter the same tree (that's more of an exception
than the rule). For bugs that we find in Linus tree, fixes enter usb,
kvm, block, sound, linux-next and a bunch of other trees that I never
heard of. At the very least we will need a git repo address + commit
hash. But then for say linux-next hashes disappear. And mm which is
not a git tree at all (no hashes).
And still the hashes will need to be explicitly marked as fixes (with
#syz fix or something else). So that would look like:
##syz fix: git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
e7989f973ae1b90ec7c0b671c81f7f553affccbe
which does not look much better than:
##syz fix: tun: do not arm flow_gc_timer in tun_flow_init()
which also I think makes it easier for humans to ensure that they
actually reference what they meant to reference (and maybe find the
fix in other trees).