linux-kernel - Re: KASAN: use-after-free Read in binder_release

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] [day] [month] [year] [list]

Message-ID: <CACT4Y+ZbkZaLfYtz6v+9FvB-3G6=6eAGHE1HGvXtGdOh2zYZdQ@mail.gmail.com>
Date:   Mon, 23 Apr 2018 15:46:25 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Martijn Coenen <maco@...roid.com>
Cc:     Eric Biggers <ebiggers3@...il.com>,
        Arve Hjønnevåg <arve@...roid.com>,
        "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Todd Kjos <tkjos@...roid.com>,
        syzbot <syzbot+0cf1f1aa154f56ff2e8d@...kaller.appspotmail.com>
Subject: Re: KASAN: use-after-free Read in binder_release_work

On Mon, Apr 23, 2018 at 3:28 PM, Martijn Coenen <maco@...roid.com> wrote:
> On Mon, Apr 23, 2018 at 12:17 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>> syzbot does not extract this info from patch emails.
>
> Ok so IIUC, Reported-By tags will only be considered when they are
> actually part of commits in one of the tested trees - makes sense. So
> does sending "#syz fix: xyz" cause syzbot to look inside all the trees
> it analyzes for xyz and mark it as closed if found? Does it look
> immediately or on some schedule, and does it retry? In this case, I
> think my patch wasn't in any tree yet when you sent "#syz fix", only
> in Greg's queue (Greg actually pushed it half an hour after your
> message). Just want to make sure I do the right thing next time.

When syzbot web app receives "syz fix" it notes the association. You
can now see it here:
https://syzkaller.appspot.com/bug?id=952e31f49f15c6de449295b8920dcc4ed935ebbf

Commits: ANDROID: binder: prevent transactions into own process.

Then, when test machines pull/build kernel, they send to the web app
which of the pending commits they see in own tree.
On the dashboard you can now see this line:

Patched on: [], missing on: [ci-upstream-bpf-next-kasan-gce
ci-upstream-kasan-gce ci-upstream-kasan-gce-386
ci-upstream-kasan-gce-root ci-upstream-kmsan-gce
ci-upstream-net-kasan-gce]

which means that no tested kernel yet have this commit.
Later the "Patched on" list will be populates as the commit reaches
the trees and test machines rebuild kernels. When all trees are
patched, the bug will be closed.


>> First of all, it's not possible to discover them all.
>> Second, a mailed patch does not mean committed patch. v2 can be resent
>> and potentially change title too.
>>
>> syzbot takes this info from commits in the tree it tests. It probably
>> could extract some emails from the commit. But they can come months
>> later, so their value will be questionable. Also consider that 2
>> commits in different trees mention the same bug. syzbot generally
>> overwrites old info with new info, because that's the only way to fix
>> up things. Now this can lead to infinite stream of emails saying that
>> this commit fixes this bug, no that commit fixes this bug, no this
>> commit fixes this bug, etc.
>> Also consider that a bug is first marked as fixed with some commit,
>> bug later is marked as dup of another or re-marked as fixed with
>> another commit. You won't get a notification, because the whole
>> sequence looks reasonable.
>> This can also lead to problems when commits backported to
>> android/chromeos trees that syzbot also tests. There these fix tags
>> look plain bogus because they reference upstream bug, not
>> android/chromeos bugs.
>>
>> By default we try to keep syzbot silent and non-spammy. And we do not
>> seem to have lots of such cases where things are somewhat messed. And
>> in all cases it should come to eventual consistency. If something is
>> marked as fixed prematurely, syzbot will open another bug. If
>> something is not marked as fixed (or marked as fixed with a
>> non-existent commit), then these bugs still hang on the dashboard and
>> visible.
>>
>>
>>>>> Thanks,
>>>>> Martijn
>>>>>
>>>>>> Now syzbot already skips list_del frame and takes the next one, so it
>>>>>> should become slightly better.
>>>>>>
>>>>>> Let's close this one with the binder fix (since that one was closed
>>>>>> with an rdma fix):
>>>>>>
>>>>>> #syz fix: ANDROID: binder: prevent transactions into own process.