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]

Date:   Mon, 30 Oct 2017 20:52:33 +0300
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 8:47 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Mon, 2017-10-30 at 18:40 +0100, Dmitry Vyukov wrote:
>> 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).
>
>
> I suggested that syzbot catches up on standard way :
>
> <SHA1>  patch title
>
> It contains way more information than :
>
> sys fix: patch title
>
> I never suggested to only use <SHA1>

But people reference patches for other reasons (I've sent you examples
offline). If you mean

syz fix: <SHA1>  patch title

then that's doable. If we agree on this format, then I am ready to
implement this.