memory leak in prepare_creds

From: INT MAX
Date: Thu Jan 27 2022 - 08:31:22 EST


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