[BUG REPORT] memory leak in prepare creds triggered by Netlink/fremovexattr (v6.12.62 , found C repro for Invalid bugs)

[Paul Moore]

On Tue, Dec 30, 2025 at 10:11 PM wangqing <wangqing7171 at gmail.com> wrote:
> On Thu, 25 Dec 2025 at 19:12, yuhang hang <yangyuhang0619 at gmail.com> wrote:
> > BUG: memory leak
> > unreferenced object 0xffff888023928000 (size 184):
> >   comm "syz-executor", pid 10631, jiffies 4294970296
> >   hex dump (first 32 bytes):
> >     01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >   backtrace (crc 1adddbfd):
> >     kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
> >     slab_post_alloc_hook mm/slub.c:4152 [inline]
> >     slab_alloc_node mm/slub.c:4197 [inline]
> >     kmem_cache_alloc_noprof+0x29a/0x320 mm/slub.c:4204
> >     prepare_creds+0x2e/0x760 kernel/cred.c:212
> >     copy_creds+0xa7/0xa50 kernel/cred.c:312
> >     copy_process+0xf7d/0x8b20 kernel/fork.c:2262
> >     kernel_clone+0xeb/0x900 kernel/fork.c:2810
> >     __do_sys_clone+0xcf/0x120 kernel/fork.c:2953
> >     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> >     do_syscall_64+0xcb/0x220 arch/x86/entry/common.c:83
> >     entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > BUG: memory leak
> > unreferenced object 0xffff88802067d920 (size 16):
> >   comm "syz-executor", pid 10631, jiffies 4294970296
> >   hex dump (first 16 bytes):
> >     00 00 00 00 00 00 00 00 00 3d 08 1b 80 88 ff ff  .........=......
> >   backtrace (crc 8e8e0e90):
> >     kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
> >     slab_post_alloc_hook mm/slub.c:4152 [inline]
> >     slab_alloc_node mm/slub.c:4197 [inline]
> >     __do_kmalloc_node mm/slub.c:4331 [inline]
> >     __kmalloc_noprof+0x331/0x460 mm/slub.c:4344
> >     kmalloc_noprof include/linux/slab.h:882 [inline]
> >     kzalloc_noprof include/linux/slab.h:1014 [inline]
> >     lsm_blob_alloc security/security.c:685 [inline]
> >     lsm_blob_alloc security/security.c:678 [inline]
> >     lsm_cred_alloc security/security.c:702 [inline]
> >     security_prepare_creds+0x294/0x320 security/security.c:3240
> >     prepare_creds+0x54e/0x760 kernel/cred.c:242
> >     copy_creds+0xa7/0xa50 kernel/cred.c:312
> >     copy_process+0xf7d/0x8b20 kernel/fork.c:2262
> >     kernel_clone+0xeb/0x900 kernel/fork.c:2810
> >     __do_sys_clone+0xcf/0x120 kernel/fork.c:2953
> >     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> >     do_syscall_64+0xcb/0x220 arch/x86/entry/common.c:83
> >     entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Hi,
>
> I've analyzed the kmemleak output and the copy_process() code path.
> The allocation happens in prepare_creds(), but all error paths after
> copy_creds() correctly call exit_creds() to release the credential.
>
> This is likely a false positive caused by RCU delayed freeing of
> struct cred. The object is queued via call_rcu() and not immediately
> freed, so kmemleak may report it as "unreferenced" before the grace
> period completes.
>
> To verify, please:
> 1. Run `echo scan > /sys/kernel/debug/kmemleak`
> 2. Wait 2-3 seconds
> 3. Run `echo scan > /sys/kernel/debug/kmemleak` again
> 4. Check if the report disappears.
>
> If it persists across multiple scans, then it might be a real leak.

Thanks for looking into this, if you are able to confirm that this is
a real leak, please let us know.

-- 
paul-moore.com