"general protection fault in hugetlbfs_get_inode" in Linux kernel version 6.13.0-rc2

"general protection fault in hugetlbfs_get_inode" in Linux kernel version 6.13.0-rc2

[cheung wall]

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.

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]
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
__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

Re: "general protection fault in hugetlbfs_get_inode" in Linux kernel version 6.13.0-rc2

[Muchun Song]

> On Jan 3, 2025, at 15:27, cheung wall <zzqq0103.hey@gmail.com> 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