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