From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AFDC31C1F10 for ; Fri, 3 Jan 2025 08:21:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735892477; cv=none; b=LsRGt3fciaInuJ2PXnAALUZa/Lq+yPTy1k4/4YsMOuwCGd98t9k8NimBoz3rNEZJwUXTcZCbZSFbTmDZUg/OCv0kRJBSowK3qheP3xzFLlW7d7Tg/HLk3DK7ejKZIb5bA4xz09BSxCihgGdrQKvu/HEiJRHBR9iz+aOVNlyUtd4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735892477; c=relaxed/simple; bh=emMJbGkokmsUKQODCOHl8sC0+lwTGfjCOxOmhq0pBzk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=RPF+UHhrytKhdVRg4C7rsyRC3Q4dJMfwxR14tgDT49RW5vU7/q6Qi/9GuTCIYjaSimBgUjzfOZymjvczTUgCJXEjfkXLV7obD5A/KQy50+2TXc1ruIJpgdEMmz/V5GV7Z37VeZ1FvrGqJdZjRkuw3yzthbL5S9JGsPnXxlfWjzc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=b5Wvvl8A; arc=none smtp.client-ip=91.218.175.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="b5Wvvl8A" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1735892468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kk07pFYK0ZIiaMNqLjNZO4u1dR8DdN703vdM0KCRBSM=; b=b5Wvvl8AMWepFFqmUq7s53ATYfleodn06fyYKJej5uRiIgJFno1tZM/xgcE64Cf5bhOURB s5DyfM8lOJkSkQI1uSm3JZuHilUJznde2OpFx90Fjxg05HufjmDj+M+ELJx7mcQzxtFciP 7Qxy28fiVVoE+Ke+zEqG3IOekx6zAMc= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: "general protection fault in hugetlbfs_get_inode" in Linux kernel version 6.13.0-rc2 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Fri, 3 Jan 2025 16:20:31 +0800 Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <02858D60-43C1-4863-A84F-3C76A8AF1F15@linux.dev> References: To: cheung wall X-Migadu-Flow: FLOW_OUT > On Jan 3, 2025, at 15:27, cheung wall wrote: >=20 > Hello, >=20 > 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. >=20 > HEAD commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 (tag: v6.13-rc2) >=20 > Affected File: fs/hugetlbfs/inode.c >=20 > File: fs/hugetlbfs/inode.c >=20 > Function: hugetlbfs_get_inode >=20 > Detailed Call Stack: >=20 > ------------[ cut here begin]------------ >=20 > 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 =3D inode->i_sb->s_dev; __entry->ino =3D inode->i_ino; __entry->dir =3D dir->i_ino; The causing line should be this one for accessing dir->i_ino. I suppose = dir is NULL. __entry->mode =3D 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: > > 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 > >=20 > ------------[ cut here end]------------ >=20 > Root Cause: >=20 > 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. >=20 > Thank you for your time and attention. >=20 > Best regards >=20 > Wall