From nobody Sat Feb 7 08:29:15 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9DEE414F115; Sun, 24 Mar 2024 23:02:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711321344; cv=none; b=P4PUzXZG8dqVnQq804ot7dYxXEeLwpLMPkZU3RCb9DDHjPchD7DWVpHBaks+OnJd6V4u4u8dqqVuXj1lGbK0KEK7i5rS5OTEXqr1p3H7dxKFLGmRRtlTHGe2HxHJDWY4sM0YPaJqJ6TPnIdBDRapMAD8HhkdjN8dkurQ6YSbbj8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711321344; c=relaxed/simple; bh=XBHbYPR8C3NkL6EjNIF6UM5IMap2ZDW4fEy/kjUMKuw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rEZmc4qUJkW6+vUkvYXqQXL+66kxBQHl4IMtkZkcSuUjuuA6Q99khO/l/0I0/VLa0+xjgXKERVkt591Byv0wiNnJA5AxPjlA5XylRm/iNhPB3MuBfL1ISGzdjXE1QnSyUkPrZROazQiC/x06g9g2IiGJ9AETLaaXpws9lZnbfyE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DFfyMt0I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DFfyMt0I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98E70C43394; Sun, 24 Mar 2024 23:02:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711321343; bh=XBHbYPR8C3NkL6EjNIF6UM5IMap2ZDW4fEy/kjUMKuw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DFfyMt0I+a9vu1Chct3xFeO59bAma23dypLp6UMyWEHhSOL4HqsqiEkKtJW3QhMT/ 5UvBgSC2i/KaR20gZCfFUJGhHaTparaUHCZ06+mbAvBvDAwWwQwuV/HzfKWIkPrBQR IimnkUJFHKBLAj++IPutZ+gSs03TWExwuOq1uCFEGqaO9QovjW3YxsWoIKoXEgt2/J AwIkYDvFg/p35JaqEqYiFK1ynMHLknHPg24idVRTv0zD2l6n7xJZuvObm3oEZ9SiL1 0H5qXUTf25uQFod0VfQaE6Bq3lo9dOdc+bfAar+dHPqYaD1HX6e5RA4FuJ9d3Y7xnp 3YQVR+jpKcM2w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nikita Zhandarovich , Chuck Lever III , syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com, Jan Kara , Christian Brauner , Sasha Levin Subject: [PATCH 6.6 067/638] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak Date: Sun, 24 Mar 2024 18:51:44 -0400 Message-ID: <20240324230116.1348576-68-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324230116.1348576-1-sashal@kernel.org> References: <20240324230116.1348576-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nikita Zhandarovich [ Upstream commit 3948abaa4e2be938ccdfc289385a27342fb13d43 ] syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instr= umented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III Reported-and-tested-by: Signed-off-by: Nikita Zhandarovich Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintec= h.ru Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 6ea8d35a9382a..99dcf07cfecfe 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -40,7 +40,7 @@ static long do_sys_name_to_handle(const struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; =20 - handle =3D kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle =3D kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; --=20 2.43.0