linux-kernel - Re: Observation of a memory leak with commit 314001f0bf92 ("af

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

Date:   Mon, 10 Jan 2022 16:15:06 +0100
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Shoaib Rao <rao.shoaib@...cle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Sudip Mukherjee <sudip.mukherjee@...ethink.co.uk>
Subject: Re: Observation of a memory leak with commit 314001f0bf92 ("af_unix:
 Add OOB support")

On Sun, Jan 9, 2022 at 7:49 AM Hillf Danton <hdanton@...a.com> wrote:
>
> On Sun, 9 Jan 2022 05:10:48 +0100 Lukas Bulwahn wrote:
> > On Fri, Jan 7, 2022 at 6:55 PM Shoaib Rao <rao.shoaib@...cle.com> wrote:
> > >
> > > Hi Lukas,
> > >
> > > I took a look at the patch and I fail to see how prepare_creds() could
> > > be impacted by the patch. The only reference to a cred in the patch is
> > > via maybe_add_creds().
> > >
> > > prepare_creds() is called to make a copy of the current creds which will
> > > be later modified. If there is any leak it would be in the caller not
> > > releasing the memory. The patch does not do anything with creds.
> > >
> > > If there is any more information that can help identify the issue, I
> > > will be happy to look into it.
> > >
> >
> > Here is more information:
> >
> > Here are all crash reports:
> >
> > https://elisa-builder-00.iol.unh.edu/syzkaller-next/crash?id=1dcac8539d69ad9eb94ab2c8c0d99c11a0b516a3
>
> More weid is the failure of Ctrl-f "unix" at [1] except for a bunch of
> clone. Can you specify why report at [1] has a direct link to af_unix?
>
>         Hillf
>
> [1] https://elisa-builder-00.iol.unh.edu/syzkaller-next/file?name=crashes%2f1dcac8539d69ad9eb94ab2c8c0d99c11a0b516a3%2freport15
>

Hillf,

I agree that is really weird. I fear we have some issue with our
syzkaller instance, somehow the database is collecting error logs that
seem to be different from the error logs I observe when manually
running the reproducer. The heuristics of aggregating error messages
is black magic.

Importantly, we have a reproducer, which is clearly related to the
af_unix functionality and we can manually trigger a reasonable error
trace. Ignore all the rest.

Lukas