Re: KASAN: use-after-free Write in detach_if_pending

From: Eric Dumazet
Date: Mon Oct 30 2017 - 13:48:00 EST


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@xxxxxxxxx> 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>