From patchwork Wed Feb 12 08:15:05 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: GONG Ruiqi X-Patchwork-Id: 13971345 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D00C0C02198 for ; Wed, 12 Feb 2025 08:05:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C72A6B0099; Wed, 12 Feb 2025 03:05:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 078476B009A; Wed, 12 Feb 2025 03:05:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E334F6B009B; Wed, 12 Feb 2025 03:05:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B65B96B009A for ; Wed, 12 Feb 2025 03:05:10 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5EE6E80FFE for ; Wed, 12 Feb 2025 08:05:10 +0000 (UTC) X-FDA: 83110557180.30.D232706 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf18.hostedemail.com (Postfix) with ESMTP id C80BD1C000D for ; Wed, 12 Feb 2025 08:05:07 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of gongruiqi1@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=gongruiqi1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739347508; h=from:from:sender: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=oYyHvW4coYfzPvMPqnsexJQkSHMMN+wKKdea3pwq9So=; b=VJQN1SwyUcOhOGdHWl7/xomZk1ah0Et0MtgrNV7+DcpZ2siYrSVjp7Z65dQ5VpLgpaD+lz HDPq+c/iJL+HytrrkPZ40U9qufPGzKyyVJ9RfXGXcqspnZ4KOox7p+ycjoKe/quwFbFkzV zDAnVB58HRjNCE+W4SRqmzlPVD4FMWs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739347508; a=rsa-sha256; cv=none; b=KiEL7sSfpjtJi+J5kSxIlyCxb8qWkxNCQ1S20PMGeZeRIAERoa8CYgLHu3qdLDd7KZOYH6 2MBzal1YvrpuIooGH0myFp9nfhJk5sS7UUTTT8R3pWpVrhoDyUluBjzwUxyAsBfCnO8F/L R57ZEkJV43nIuaw5TCpODpB/++zZeIo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of gongruiqi1@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=gongruiqi1@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4Yt9py3ckMz20qK9; Wed, 12 Feb 2025 16:05:30 +0800 (CST) Received: from kwepemg100016.china.huawei.com (unknown [7.202.181.57]) by mail.maildlp.com (Postfix) with ESMTPS id 1540E1A0188; Wed, 12 Feb 2025 16:05:01 +0800 (CST) Received: from huawei.com (10.67.174.33) by kwepemg100016.china.huawei.com (7.202.181.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 12 Feb 2025 16:05:00 +0800 From: GONG Ruiqi To: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Kees Cook CC: Tamas Koczka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Xiu Jianfeng , , , , Subject: [PATCH v3 2/2] slab: Achieve better kmalloc caches randomization in kvmalloc Date: Wed, 12 Feb 2025 16:15:05 +0800 Message-ID: <20250212081505.2025320-3-gongruiqi1@huawei.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20250212081505.2025320-1-gongruiqi1@huawei.com> References: <20250212081505.2025320-1-gongruiqi1@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.67.174.33] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemg100016.china.huawei.com (7.202.181.57) X-Rspam-User: X-Rspamd-Queue-Id: C80BD1C000D X-Rspamd-Server: rspam07 X-Stat-Signature: y5kmhbu4469cbdrhm6dd8k43btkf55ox X-HE-Tag: 1739347507-518690 X-HE-Meta: U2FsdGVkX18u6tDzw7aVUrYXIzFRqRizNOKfIrTFr3kWeQCczXNiY/UtpoeC2/gu549nTXc7tczQygHV0cBu+nz/gHb/Kaz9ylkobPZyta17wZQkvwxkIxu5gFBROHNyuJbx+bt4g8ZUtwgAYdfc0vtnMRus69rpU+Pg/EYFXfYD5UTF5HTpk4ZJTtXrxtRGNujC7E4kpfV0TlWJNH7v6xRhcr/MhwCa10AFU5W2RsYPHctcTScXj5skBj47I8EMHkypwJ0Hlog06TQIjO7hE2pCMLRTTTQAuXsgLWttRLbdPNMvGE9yaHmE8k+INY2HzzSTAnVbad7xwunuluRSlUTKNIjJyC3beovzxRnMEjCUVR7kM7xQlKcTH4OVgduAG5JubQQ/0krVqqfbUiXE/nT7359ELzKeNH//fk7T4qzJO1z0Nmtt7DDmEXC1aTLwkVi4gYkpcIlzeLSiJZrP8TKeNH4FqRPGPIyI89sYJQVSnb7/8c5gcWLdK0DwqREVHtu3RehRqobJ5tH/XRRSA3E5cPMLnXAmc4F1N+rD0glDlEW7q2CxojvaFngBEgqN9VDElTzf0VHaEJKbpYP47kguseZlsVX0D9TzSR8j7Ev3YGCNbmTURP59wutRF958LwZvDJqvvSWE5KdIKKNeWz4xcuMx0Enl/wXwYQXIq9v1/AJDMJuNduGT3mmGROaVi4dNaHT6u52TtBKYhbP+7jGg54jQEttqvZit7JtvH4xkhr2/WeYEcaazwFMSt+Zpo9SPGhyej2xC+arRcVddTfxtxKgqXK24wZHUnxyZsVgJkMyawKrjTnvzra6+VokZkR3QgggqWfUgJ2QZnvUC1rnY2toIFInx7Vfr58phdiHlWU42yNaG/C4riiBm1p8JNTP25B74Tn0xtTZeF+5j5Y8iffW3PH3j9ScRC9LoGhPUbyymdp2rmcbeazZiDatuomiB872PPGhFyhZNPmb jkOrfOl0 xNBBupTQ4+iBjpHVC+4o+P75uSnYbOQqlYhthSk9J/+RYIxDb7VovmW1xDh+YSjcFiqaVqLmEHdi05hFEXHNgeXLddUbj/kh9BoYuOG20dJS5Cwc0PhvHSd5hBRqtJEuNKCq5y/kT4saRjqGwtHZMBZmdvm34eDWZJ7fXZ9yR2BI3WAKvED9dVcbMtMkC7TUtACoK0CjnkOTmi5w9RQOlfholHIRnEZb+1vNysG783CI0i8avod5oxwmhuOnceWn7cuW/x7lSa9i7MvJGuCpdztdC3SfoEZbxyPX2peN793zjb44= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: As revealed by this writeup[1], due to the fact that __kmalloc_node (now renamed to __kmalloc_node_noprof) is an exported symbol and will never get inlined, using it in kvmalloc_node (now is __kvmalloc_node_noprof) would make the RET_IP inside always point to the same address: upper_caller kvmalloc kvmalloc_node kvmalloc_node_noprof __kvmalloc_node_noprof <-- all macros all the way down here __kmalloc_node_noprof __do_kmalloc_node(.., _RET_IP_) ... <-- _RET_IP_ points to That literally means all kmalloc invoked via kvmalloc would use the same seed for cache randomization (CONFIG_RANDOM_KMALLOC_CACHES), which makes this hardening non-functional. The root cause of this problem, IMHO, is that using RET_IP only cannot identify the actual allocation site in case of kmalloc being called inside non-inlined wrappers or helper functions. And I believe there could be similar cases in other functions. Nevertheless, I haven't thought of any good solution for this. So for now let's solve this specific case first. For __kvmalloc_node_noprof, replace __kmalloc_node_noprof and call __do_kmalloc_node directly instead, so that RET_IP can take the return address of kvmalloc and differentiate each kvmalloc invocation: upper_caller kvmalloc kvmalloc_node kvmalloc_node_noprof __kvmalloc_node_noprof <-- all macros all the way down here __do_kmalloc_node(.., _RET_IP_) ... <-- _RET_IP_ points to Thanks to Tamás Koczka for the report and discussion! Link: https://github.com/google/security-research/blob/908d59b573960dc0b90adda6f16f7017aca08609/pocs/linux/kernelctf/CVE-2024-27397_mitigation/docs/exploit.md?plain=1#L259 [1] Reported-by: Tamás Koczka Signed-off-by: GONG Ruiqi --- mm/slub.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index abc982d68feb..1f7d1d260eeb 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4925,9 +4925,9 @@ void *__kvmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, int node) * It doesn't really make sense to fallback to vmalloc for sub page * requests */ - ret = __kmalloc_node_noprof(PASS_BUCKET_PARAMS(size, b), - kmalloc_gfp_adjust(flags, size), - node); + ret = __do_kmalloc_node(size, PASS_BUCKET_PARAM(b), + kmalloc_gfp_adjust(flags, size), + node, _RET_IP_); if (ret || size <= PAGE_SIZE) return ret;