linux-kernel - Re: syzbot bisection analysis

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACT4Y+bDD8s1cbMOad_S=8f=MAMagiOpZJZnQTNwBU5skm3ycQ@mail.gmail.com>
Date:   Tue, 30 Jul 2019 11:16:43 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     syzkaller <syzkaller@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Eric Biggers <ebiggers@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: syzbot bisection analysis

On Mon, Jul 29, 2019 at 3:36 PM Catalin Marinas <catalin.marinas@....com> wrote:
>
> Hi Dmitry,
>
> On Mon, Jul 29, 2019 at 01:08:16PM +0200, Dmitry Vyukov wrote:
> > The remaining 10 were all diverged due to other unrelated memory leaks
> > and other non-leak bugs. It seems the main 2 reasons for this:
> > 1. Lots of leaks are old (kernel is under-tested with KMEMLEAK).
> > 2. Lots of unrelated bugs.
> > It's unclear how much KMEMLEAK potential for false positives is in
> > play. For example, lots of bisections are diverged by "memory leak in
> > batadv_tvlv_handler_register", but this is a true bug reported at:
> > https://syzkaller.appspot.com/bug?id=0654529ad3cc1d67a6d9812d8b75489c03dfb983
> > However, some are diverged by e.g. "memory leak in __neigh_create" and
> > "memory leak in copy_process" and these were not reported as separate
> > leaks, so either false positives or true leaks fixed in previous
> > releases.
>
> Out of curiosity, when the tool tries to bisect a memory leak, does it
> check for precisely that leak (e.g. by function name, object size) or
> any other unrelated leak can confuse the bisection?

Bisection of leaks uses the common scheme which is just "crashed"/"not
crashed" (black/white, no further classification) for reasons outlined
here:
https://groups.google.com/forum/#!msg/syzkaller/sR8aAXaWEF4/tTWYRgvmAwAJ
Consider object size changes across revisions, or the function is
renamed, or code changes. Even if we take just leaks, I am not sure if
it's possible to understand if it's the same leak or not.