From mboxrd@z Thu Jan 1 00:00:00 1970 From: syzbot Subject: Re: KASAN: use-after-free Write in detach_if_pending Date: Mon, 30 Oct 2017 10:40:37 -0700 Message-ID: <94eb2c189574effd6d055cc72269@google.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Cc: davem@davemloft.net, dvyukov@google.com, eric.dumazet@gmail.com, jasowang@redhat.com, john.stultz@linaro.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, sboyd@codeaurora.org, syzkaller-bugs@googlegroups.com, tglx@linutronix.de To: Dmitry Vyukov Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org > On Mon, Oct 30, 2017 at 6:30 PM, Eric Dumazet > 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).