[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20251231031117.37793-1-wq513132@alibaba-inc.com>
Date: Wed, 31 Dec 2025 11:11:17 +0800
From: wangqing <wangqing7171@...il.com>
To: yangyuhang0619@...il.com
Cc: jmorris@...ei.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
paul@...l-moore.com,
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 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.
--
Best regards,
Qing Wang
Powered by blists - more mailing lists