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
| ||
|
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
Powered by blists - more mailing lists