linux-kernel - memory leak in prepare

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CACvCHSL-mmcvfjuCkhZSvfddojPuAOq8cnjxt8Tu9He2s_LRGw@mail.gmail.com>
Date:   Thu, 27 Jan 2022 21:31:05 +0800
From:   INT MAX <untitled.yan@...il.com>
To:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: memory leak in prepare_creds

Dear maintainers,

I've found a memory leak bug in prepare_creds in kernel v5.16
(df0cc57e057f18e44dac8e6c18aba47ab53202f9) using Syzkaller. It happens after
fork-pipe2-close_range (a stable reproducer attached below). It's possibly
caused by incorrect reference counting of credentials after pipe2-close_range.

I tried adding some debug messages to trace "get_cred" and "put_cred" but it
seems the reference count is changed somewhere else. Unfortunately, adding more
debug messages makes it no longer reproducible. But there is one thing for sure
the reported leaked cred was indeed not freed by "__put_cred".

Attached are the following for your reference:

1. Syzkaller report (including a C reproducer at the end of the report with
   some extra debug info added by me): https://pastebin.com/xMWNhf5r.
   The reproducer will usually report the leak after 2 or more iterations, but
   the actual leak may happen in the first iteration by inspecting the debug
   output where the leaked "cred" object was reported to be created as early as
   in the first iteration, and never get destroyed. In addition, the number of
   iterations required for triggering the leak goes down to 1 after running the
   reproducer multiple times.
2. Debug output (added by me) during the lifecycle of "ls" (no leak) as
   reference: https://pastebin.com/L45kbnwt.
3. Debug output during the lifecycle of "sleep 0" (no leak) as reference:
   https://pastebin.com/XFM5r1sF.
4. Debug output during the lifecycle of "repro" (the C reproducer; leaked):
   https://pastebin.com/yj2evZbX.
5. The kernel config: https://pastebin.com/DU0VVviE.

[This email is resent to the two mailing lists because the previous
email sent via outlook is blocked.]

Best regards,
Untitled YAN