Re: Observation of a memory leak with commit 314001f0bf92 ("af_unix: Add OOB support")

From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
To: Hillf Danton <hdanton@sina.com>
Cc: Shoaib Rao <rao.shoaib@oracle.com>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Netdev <netdev@vger.kernel.org>,
	Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Subject: Re: Observation of a memory leak with commit 314001f0bf92 ("af_unix: Add OOB support")
Date: Mon, 10 Jan 2022 16:15:06 +0100	[thread overview]
Message-ID: <CAKXUXMwL5ThVG-LtcUwiC3qTS6CMObSB7m=vpGENUzERYaGeaQ@mail.gmail.com> (raw)
In-Reply-To: <20220109064905.1594-1-hdanton@sina.com>

On Sun, Jan 9, 2022 at 7:49 AM Hillf Danton <hdanton@sina.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@oracle.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