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

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: <02858D60-43C1-4863-A84F-3C76A8AF1F15@linux.dev>
Date: Fri, 3 Jan 2025 16:20:31 +0800
From: Muchun Song <muchun.song@...ux.dev>
To: cheung wall <zzqq0103.hey@...il.com>
Cc: linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: "general protection fault in hugetlbfs_get_inode" in Linux kernel
 version 6.13.0-rc2



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