> On Jan 3, 2025, at 15:27, cheung wall <zzqq0103.hey@xxxxxxxxx> wrote: > > Hello, > > I am writing to report a potential vulnerability identified in the > Linux Kernel version 6.13.0-rc2. This issue was discovered using our > custom vulnerability discovery tool. Thanks for your report. > > HEAD commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 (tag: v6.13-rc2) > > Affected File: fs/hugetlbfs/inode.c > > File: fs/hugetlbfs/inode.c > > Function: hugetlbfs_get_inode > > Detailed Call Stack: > > ------------[ cut here begin]------------ > > KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] I think it is accessing ->i_ino field since it is offset is 0x40 and size is 8 bytes. TP_fast_assign( __entry->dev = inode->i_sb->s_dev; __entry->ino = inode->i_ino; __entry->dir = dir->i_ino; The causing line should be this one for accessing dir->i_ino. I suppose dir is NULL. __entry->mode = mode; ), > CPU: 0 UID: 0 PID: 4946 Comm: syz-executor.3 Not tainted > 6.13.0-rc2-00159-gf932fb9b4074 #1 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 > RIP: 0010:do_perf_trace_hugetlbfs_alloc_inode > include/trace/events/hugetlbfs.h:10 [inline] > RIP: 0010:perf_trace_hugetlbfs_alloc_inode+0x2bf/0x5f0 > include/trace/events/hugetlbfs.h:10 > Code: 80 3c 11 00 0f 85 1c 02 00 00 48 8b b5 50 ff ff ff 4c 89 68 10 > 48 ba 00 00 00 00 00 fc ff df 48 8d 7e 40 48 89 f9 48 c1 e9 03 <80> 3c > 11 00 0f 85 cc 01 00 00 48 8d 78 18 48 8b b5 50 ff ff ff 48 > RSP: 0018:ffff888108e8fda8 EFLAGS: 00010212 > RAX: ffffe8ffffc2f000 RBX: 1ffff110211d1fba RCX: 0000000000000008 > RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000040 > RBP: ffff888108e8fe78 R08: 0000000000000004 R09: ffff88811b2351e0 > R10: ffffe8ffffc2f024 R11: 0000000000032001 R12: ffffffff8e1274e0 > R13: 0000000000001947 R14: ffffe8ffffc06390 R15: ffff888108e8fe50 > FS: 00007f3518797640(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000001b2e22d000 CR3: 0000000103716000 CR4: 0000000000350ef0 > Call Trace: > <TASK> > trace_hugetlbfs_alloc_inode include/trace/events/hugetlbfs.h:10 [inline] > hugetlbfs_get_inode+0x2a2/0x480 fs/hugetlbfs/inode.c:973 > hugetlb_file_setup+0x11e/0x510 fs/hugetlbfs/inode.c:1557 hugetlb_file_setup pass a NULL dir to hugetlbfs_get_inode, so my guess is right. I'll send a fix patch later to fix this. Muchun, Thanks. > __do_sys_memfd_create+0x278/0x7b0 mm/memfd.c:388 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xa6/0x1a0 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f35194b842d > Code: c3 e8 97 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 > 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007f3518797038 EFLAGS: 00000246 ORIG_RAX: 000000000000013f > RAX: ffffffffffffffda RBX: 00007f35196abf80 RCX: 00007f35194b842d > RDX: 0000000000000000 RSI: 0000000000000007 RDI: 00000000200000c0 > RBP: 00007f3519577922 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > R13: 0000000000000006 R14: 00007f35196abf80 R15: 00007f3518777000 > </TASK> > > ------------[ cut here end]------------ > > Root Cause: > > The crash is caused by a null pointer dereference detected by > KernelAddressSANitizer (KASAN) within the > do_perf_trace_hugetlbfs_alloc_inode function of the Linux kernel's > hugetlbfs subsystem. Specifically, during the allocation of an inode > for hugetlbfs through the memfd_create system call, the performance > tracing mechanism (perf_trace_hugetlbfs_alloc_inode) attempts to > access memory at an invalid address range (0x40-0x47). This likely > occurs because a required pointer within the inode structure or > associated tracing data is either uninitialized or set to NULL. As a > result, when the kernel's performance tracing infrastructure tries to > log the inode allocation event, it inadvertently dereferences a null > or improperly initialized pointer, leading to a null-ptr-deref error > and subsequent kernel crash. This issue highlights a deficiency in the > initialization or validation of pointers within the hugetlbfs inode > allocation path, particularly in the context of integrating with > performance tracing features. > > Thank you for your time and attention. > > Best regards > > Wall
