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

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHC9VhQYf79Ni3M1r_F2L=vKtDyqOU3Rim+q480OB7Rzam+6xg@mail.gmail.com>
Date: Wed, 31 Dec 2025 09:47:39 -0500
From: Paul Moore <paul@...l-moore.com>
To: wangqing <wangqing7171@...il.com>
Cc: yangyuhang0619@...il.com, jmorris@...ei.org, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, serge@...lyn.com, 
	syzkaller-bugs@...glegroups.com
Subject: Re: [BUG REPORT] memory leak in prepare creds triggered by
 Netlink/fremovexattr (v6.12.62 , found C repro for Invalid bugs)

On Tue, Dec 30, 2025 at 10:11 PM wangqing <wangqing7171@...il.com> wrote:
> On Thu, 25 Dec 2025 at 19:12, yuhang hang <yangyuhang0619@...il.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