From: Shoaib Rao <rao.shoaib@oracle.com>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>,
"David S. Miller" <davem@davemloft.net>
Cc: 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: Fri, 7 Jan 2022 09:54:57 -0800 [thread overview]
Message-ID: <35cebb4b-3a1d-fa47-4d49-1a516f36af4f@oracle.com> (raw)
In-Reply-To: <CAKXUXMzZkQvHJ35nwVhcJe+DrtEXGw+eKGVD04=xRJkVUC2sPA@mail.gmail.com>
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.
Note that a lot of bugs are timing related, so while it might seem that
a change is causing the problem, it may not be the cause, it may just be
changing the environment for the bug to show up.
Shoaib
On 1/6/22 22:48, Lukas Bulwahn wrote:
> Dear Rao and David,
>
>
> In our syzkaller instance running on linux-next,
> https://urldefense.com/v3/__https://elisa-builder-00.iol.unh.edu/syzkaller-next/__;!!ACWV5N9M2RV99hQ!YR_lD5j1kvA5QfrbPcM5nMVZZkWNcF-UEE4vKA20TPkslzzGDVPqpL-6heEhBZ_e$ , we have been
> observing a memory leak in prepare_creds,
> https://urldefense.com/v3/__https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=1dcac8539d69ad9eb94ab2c8c0d99c11a0b516a3__;!!ACWV5N9M2RV99hQ!YR_lD5j1kvA5QfrbPcM5nMVZZkWNcF-UEE4vKA20TPkslzzGDVPqpL-6hS1luOMv$ ,
> for quite some time.
>
> It is reproducible on v5.15-rc1, v5.15, v5.16-rc8 and next-20220104.
> So, it is in mainline, was released and has not been fixed in
> linux-next yet.
>
> As syzkaller also provides a reproducer, we bisected this memory leak
> to be introduced with commit 314001f0bf92 ("af_unix: Add OOB
> support").
>
> We also tested that reverting this commit on torvalds' current tree
> made the memory leak with the reproducer go away.
>
> Could you please have a look how your commit introduces this memory
> leak? We will gladly support testing your fix in case help is needed.
>
>
> Best regards,
>
> Lukas
next prev parent reply other threads:[~2022-01-07 17:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 6:48 Observation of a memory leak with commit 314001f0bf92 ("af_unix: Add OOB support") Lukas Bulwahn
2022-01-07 17:54 ` Shoaib Rao [this message]
2022-01-09 4:10 ` Lukas Bulwahn
[not found] ` <20220109064905.1594-1-hdanton@sina.com>
2022-01-10 15:15 ` Lukas Bulwahn
2022-01-09 21:20 ` Jakub Kicinski
2022-01-10 14:02 ` Thorsten Leemhuis
2022-01-10 16:19 ` Lukas Bulwahn
2022-01-10 16:29 ` Jakub Kicinski
2022-01-28 13:17 ` Thorsten Leemhuis
2022-01-10 16:21 ` Jakub Kicinski
2022-01-10 14:54 ` Lukas Bulwahn
2022-01-10 13:15 ` Observation of a memory leak with commit 314001f0bf92 ("af_unix: Add OOB support") #forregzbot Thorsten Leemhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35cebb4b-3a1d-fa47-4d49-1a516f36af4f@oracle.com \
--to=rao.shoaib@oracle.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sudip.mukherjee@codethink.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.