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

From: syzbot
Date: Mon Oct 30 2017 - 13:40:52 EST


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:

unknown command "fix"

##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).