From patchwork Fri Oct 21 03:24:03 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 6496 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp458893wrr; Thu, 20 Oct 2022 20:25:06 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6Dd/6YDMe6ehXyDZfdmpT50ZjAOzn7N6NKTEZCd8jGbxl3B1EtkVcd50UUniNdTavrWqEZ X-Received: by 2002:a63:2253:0:b0:43c:c924:e56a with SMTP id t19-20020a632253000000b0043cc924e56amr14064401pgm.122.1666322705918; Thu, 20 Oct 2022 20:25:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666322705; cv=none; d=google.com; s=arc-20160816; b=RKk1Y8NRH8+vNRkeOQ9yuQj4cNrP2zFspCTY71itElqE07+LetbONfLdPcXoAN5LRO d6fctJgBM0JKvu2r9jZ/+7KQyNvNh9jvr4yd0PoK/qIfBPGwln3PVdJKPBjgn2XiFi8w uB39y5nTWYdWwxyJk0PnZpKiOsTlUxjojiE6DzwYIBGYyT8fdN0tdinZBCzfNG1gK5N1 JSDNIa1sQqxQSJDf0SZUsuNUZ4bUml6Luk70k+2pqV0ANEZk16X10Pj8teEMs0waQXKz q8OeBUxrFdJAz4W2vfotIjpH0iY+GYPzMfAZgHOIDfUXNdOQY8v1f/H8M6vvg4uGxrAi VxSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=3YDxtwYk13Eg8oX62TDkjnLYaWguBEGcZS5fYx2UnH0=; b=ZpXVn8rg6fRCVF1DsjW7HeGwMCEazqgC2tqGcfWMiz1Ek5dQEKQRvoetZZCJIyfneO BGEcP2LbMwa4xdvYggK6LEn/GkQqQ4RU3yQmGQmJ9+52fqv48WvnASTp1MVoDrnNYSEQ +x1tyY4YvT+XTsWjCLI2HsZADJd8Eu5+scjpA4WAunUeWnFKCqTFztyZ8+2CzVTu0bEa S/TcVjeln3h2eAwPxiFFNC8xUPM6U1CD5bqQXtTzrAAVlkwFrpdGIDxtvXl147P4fOIH YhUUDbbCGT1tsMLJX8UE/Kz4fgBZIMQ1DIjWJ6gFaXwvCALygbnFVz1yUsmadcf/6/m5 EN3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FPaYQwtM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x138-20020a633190000000b004626957c3c7si24051549pgx.193.2022.10.20.20.24.53; Thu, 20 Oct 2022 20:25:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FPaYQwtM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229991AbiJUDYU (ORCPT + 99 others); Thu, 20 Oct 2022 23:24:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229939AbiJUDYP (ORCPT ); Thu, 20 Oct 2022 23:24:15 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B99D01B65C8 for ; Thu, 20 Oct 2022 20:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666322654; x=1697858654; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=DZlZbkmzdjTJqsSTh0PWMpWULB1+KKo5zc/qeSpD1kM=; b=FPaYQwtMlGIygD5c5XwrdlDH0d1K99m5v9aroVtLozfMUN1gN3NyZfBu 4lmZydFRf28L0vKlQRWlxu26ZLaBkSDcTBRewhZPFZf/h6dnDRKvieazA 1DHONo4f8tHtv5CTfgx/FN4s8+ZZM1BYiQ2fQ8UiLWxEA24Y3q92OJQP2 dBS1ydgX3BT73WRXdGAYqi3z1LYTqHM0pDEB/YhcthR9fFYuKoVTjWX0z Kv6wkt21djkVRZIc9QhfKSx4Qqcx3iegep4tkPn5b2gtiEWsmpCZfSWte xqsImrqjNAxo1OvFRwUjpMZrEEQFkkkjDLoOpTR6LrCWdpNMjTRi8OsMB g==; X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="333471603" X-IronPort-AV: E=Sophos;i="5.95,200,1661842800"; d="scan'208";a="333471603" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2022 20:24:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="719459559" X-IronPort-AV: E=Sophos;i="5.95,200,1661842800"; d="scan'208";a="719459559" Received: from feng-clx.sh.intel.com ([10.238.200.228]) by FMSMGA003.fm.intel.com with ESMTP; 20 Oct 2022 20:24:11 -0700 From: Feng Tang To: Andrew Morton , Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dmitry Vyukov , Andrey Konovalov , Kees Cook Cc: Dave Hansen , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Feng Tang Subject: [PATCH v7 1/3] mm/slub: only zero requested size of buffer for kzalloc when debug enabled Date: Fri, 21 Oct 2022 11:24:03 +0800 Message-Id: <20221021032405.1825078-2-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221021032405.1825078-1-feng.tang@intel.com> References: <20221021032405.1825078-1-feng.tang@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747265997472089953?= X-GMAIL-MSGID: =?utf-8?q?1747265997472089953?= kzalloc/kmalloc will round up the request size to a fixed size (mostly power of 2), so the allocated memory could be more than requested. Currently kzalloc family APIs will zero all the allocated memory. To detect out-of-bound usage of the extra allocated memory, only zero the requested part, so that redzone sanity check could be added to the extra space later. For kzalloc users who will call ksize() later and utilize this extra space, please be aware that the space is not zeroed any more when debug is enabled. (Thanks to Kees Cook's effort to sanitize all ksize() user cases [1], this won't be a big issue). [1]. https://lore.kernel.org/all/20220922031013.2150682-1-keescook@chromium.org/#r Signed-off-by: Feng Tang Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Reviewed-by: Andrey Konovalov Signed-off-by: Feng Tang Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> --- mm/slab.c | 7 ++++--- mm/slab.h | 18 ++++++++++++++++-- mm/slub.c | 10 +++++++--- 3 files changed, 27 insertions(+), 8 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index a5486ff8362a..4594de0e3d6b 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3253,7 +3253,8 @@ slab_alloc_node(struct kmem_cache *cachep, struct list_lru *lru, gfp_t flags, init = slab_want_init_on_alloc(flags, cachep); out: - slab_post_alloc_hook(cachep, objcg, flags, 1, &objp, init); + slab_post_alloc_hook(cachep, objcg, flags, 1, &objp, init, + cachep->object_size); return objp; } @@ -3506,13 +3507,13 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t flags, size_t size, * Done outside of the IRQ disabled section. */ slab_post_alloc_hook(s, objcg, flags, size, p, - slab_want_init_on_alloc(flags, s)); + slab_want_init_on_alloc(flags, s), s->object_size); /* FIXME: Trace call missing. Christoph would like a bulk variant */ return size; error: local_irq_enable(); cache_alloc_debugcheck_after_bulk(s, flags, i, p, _RET_IP_); - slab_post_alloc_hook(s, objcg, flags, i, p, false); + slab_post_alloc_hook(s, objcg, flags, i, p, false, s->object_size); kmem_cache_free_bulk(s, i, p); return 0; } diff --git a/mm/slab.h b/mm/slab.h index 0202a8c2f0d2..8b4ee02fc14a 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -720,12 +720,26 @@ static inline struct kmem_cache *slab_pre_alloc_hook(struct kmem_cache *s, static inline void slab_post_alloc_hook(struct kmem_cache *s, struct obj_cgroup *objcg, gfp_t flags, - size_t size, void **p, bool init) + size_t size, void **p, bool init, + unsigned int orig_size) { + unsigned int zero_size = s->object_size; size_t i; flags &= gfp_allowed_mask; + /* + * For kmalloc object, the allocated memory size(object_size) is likely + * larger than the requested size(orig_size). If redzone check is + * enabled for the extra space, don't zero it, as it will be redzoned + * soon. The redzone operation for this extra space could be seen as a + * replacement of current poisoning under certain debug option, and + * won't break other sanity checks. + */ + if (kmem_cache_debug_flags(s, SLAB_STORE_USER) && + (s->flags & SLAB_KMALLOC)) + zero_size = orig_size; + /* * As memory initialization might be integrated into KASAN, * kasan_slab_alloc and initialization memset must be @@ -736,7 +750,7 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s, for (i = 0; i < size; i++) { p[i] = kasan_slab_alloc(s, p[i], flags, init); if (p[i] && init && !kasan_has_integrated_init()) - memset(p[i], 0, s->object_size); + memset(p[i], 0, zero_size); kmemleak_alloc_recursive(p[i], s->object_size, 1, s->flags, flags); kmsan_slab_alloc(s, p[i], flags); diff --git a/mm/slub.c b/mm/slub.c index 12354fb8d6e4..17292c2d3eee 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3395,7 +3395,11 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s, struct list_l init = slab_want_init_on_alloc(gfpflags, s); out: - slab_post_alloc_hook(s, objcg, gfpflags, 1, &object, init); + /* + * When init equals 'true', like for kzalloc() family, only + * @orig_size bytes will be zeroed instead of s->object_size + */ + slab_post_alloc_hook(s, objcg, gfpflags, 1, &object, init, orig_size); return object; } @@ -3852,11 +3856,11 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t flags, size_t size, * Done outside of the IRQ disabled fastpath loop. */ slab_post_alloc_hook(s, objcg, flags, size, p, - slab_want_init_on_alloc(flags, s)); + slab_want_init_on_alloc(flags, s), s->object_size); return i; error: slub_put_cpu_ptr(s->cpu_slab); - slab_post_alloc_hook(s, objcg, flags, i, p, false); + slab_post_alloc_hook(s, objcg, flags, i, p, false, s->object_size); kmem_cache_free_bulk(s, i, p); return 0; } From patchwork Fri Oct 21 03:24:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 6499 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp459964wrr; Thu, 20 Oct 2022 20:28:40 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4QCNUR8tVC9hw8z0TXjt5Zg4lfcRkGro5JIw8mRFyv5g0SHiqNWMfDYdIHw/UA6pwSADD2 X-Received: by 2002:a17:906:7945:b0:73b:e605:f31 with SMTP id l5-20020a170906794500b0073be6050f31mr13923736ejo.129.1666322920457; Thu, 20 Oct 2022 20:28:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666322920; cv=none; d=google.com; s=arc-20160816; b=Ibj/HjBGFVpWrkpPiZ94FI6RC0fVpP3nSf1+erT7cdM2D86hMKiGt4XXAqSYoJW5yB YrA/ElIbMCN4JqGscJbq8XQrVXURcLwS/yLr5mXjSD6TVZHGbKa/E42B0PjwGOTH+es3 NahbJfvlmJHoBY5+qIjbV6uxuXGYLziid05HgJsJNwDQwMS+JwPgmcb6jO5CRD5ntci5 olVk9N/yBsiBwjJbfi0g7ibUeKxZYayYRC0pqmvD0iBRSCr6niA3XAht+7WPOz9BuyJt Rei35L+wKTCaUGo2Y7YwGsxUpv1nTBmRxpeX4gIE4pqCuTOFpBHNOWDEO/C3iOYN9ASi Wdxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=qT9aTG4MhKp/JZdJeVtvRHIFl7COGLInTpwNhLfWtPo=; b=hwgo7tKIKoRNrH5A+PxcskEDXF0dFsentAZ90DWiXp8ddHqiRa2aQtxkOJdwyU+A1m p9bMbbUuzD5gQ+V9MUmzLl5qYg/AEm+86OWZJ4U+P60gIfy+qsIatDUaM9lETf7QrxpE 0+Inhd67CfcXJS75EqRWLv/+shZ6IReA7H1GT7YFa+4aef1/2rFryeZpUXOqtseQGq6S JW4+eHycs5eW9cgv+R0hlLLYJWvEonEAkJe4b5k8tBin9NbD0ZKPxbMU+YSueC52DH/Q ydiDfgyShVLylmpFcfADST/Q60zTtJYjdfiGSkAdoYqPGHvCyGt4xfrlh5vLg19WeQBp DjRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=UvBTWdXZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xg11-20020a170907320b00b0077e9417b5a7si20403002ejb.938.2022.10.20.20.28.05; Thu, 20 Oct 2022 20:28:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=UvBTWdXZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230038AbiJUDYk (ORCPT + 99 others); Thu, 20 Oct 2022 23:24:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229962AbiJUDYb (ORCPT ); Thu, 20 Oct 2022 23:24:31 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 225511DDDB for ; Thu, 20 Oct 2022 20:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666322659; x=1697858659; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=TNsKWHYJLqAo/IELz04ecR5M2wF4zce2b3Ctn8SweIk=; b=UvBTWdXZfmdyCKnxuwdmvhWMuU2YzM1GMZnoR4IKEu89IDisATU9EVlv 8U5d4IVWcEnIpuc8q++HzUzC3oHoId1nMY7nKkAZDwI8ynKRdJwx2xivg S2Hv0YZlDODsbO2DBNOGreouP6uX9EZ016f+8jpO6rtYOEk6xoQA0xG+q 8/pDQZepEChWFGBl+y8w0TEwoJb1VcyM/1+1PrABvZpGgEUHokIIDh01b 2T2EtZJWKT8y5Y6Db8PX9mlBz85C1LstBRoyxayFptTKkBCfurBaU/7Rb 38c2pyEAmORjra5Vd7yngA72Qi6i7HtdiHEXZhwZsBP3oRsZOpeF530nN A==; X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="333471613" X-IronPort-AV: E=Sophos;i="5.95,200,1661842800"; d="scan'208";a="333471613" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2022 20:24:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="719459592" X-IronPort-AV: E=Sophos;i="5.95,200,1661842800"; d="scan'208";a="719459592" Received: from feng-clx.sh.intel.com ([10.238.200.228]) by FMSMGA003.fm.intel.com with ESMTP; 20 Oct 2022 20:24:14 -0700 From: Feng Tang To: Andrew Morton , Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dmitry Vyukov , Andrey Konovalov , Kees Cook Cc: Dave Hansen , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Feng Tang , kernel test robot , Andrey Ryabinin , Alexander Potapenko , Vincenzo Frascino Subject: [PATCH v7 2/3] mm: kasan: Extend kasan_metadata_size() to also cover in-object size Date: Fri, 21 Oct 2022 11:24:04 +0800 Message-Id: <20221021032405.1825078-3-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221021032405.1825078-1-feng.tang@intel.com> References: <20221021032405.1825078-1-feng.tang@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747266222557747555?= X-GMAIL-MSGID: =?utf-8?q?1747266222557747555?= When kasan is enabled for slab/slub, it may save kasan' free_meta data in the former part of slab object data area in slab object's free path, which works fine. There is ongoing effort to extend slub's debug function which will redzone the latter part of kmalloc object area, and when both of the debug are enabled, there is possible conflict, especially when the kmalloc object has small size, as caught by 0Day bot [1]. To solve it, slub code needs to know the in-object kasan's meta data size. Currently, there is existing kasan_metadata_size() which returns the kasan's metadata size inside slub's metadata area, so extend it to also cover the in-object meta size by adding a boolean flag 'in_object'. There is no functional change to existing code logic. [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu@xsang-OptiPlex-9020/ Reported-by: kernel test robot Suggested-by: Andrey Konovalov Signed-off-by: Feng Tang Reviewed-by: Andrey Konovalov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Vincenzo Frascino Reviewed-by: Andrey Konovalov --- include/linux/kasan.h | 5 +++-- mm/kasan/generic.c | 19 +++++++++++++------ mm/slub.c | 4 ++-- 3 files changed, 18 insertions(+), 10 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index d811b3d7d2a1..96c9d56e5510 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -302,7 +302,7 @@ static inline void kasan_unpoison_task_stack(struct task_struct *task) {} #ifdef CONFIG_KASAN_GENERIC -size_t kasan_metadata_size(struct kmem_cache *cache); +size_t kasan_metadata_size(struct kmem_cache *cache, bool in_object); slab_flags_t kasan_never_merge(void); void kasan_cache_create(struct kmem_cache *cache, unsigned int *size, slab_flags_t *flags); @@ -315,7 +315,8 @@ void kasan_record_aux_stack_noalloc(void *ptr); #else /* CONFIG_KASAN_GENERIC */ /* Tag-based KASAN modes do not use per-object metadata. */ -static inline size_t kasan_metadata_size(struct kmem_cache *cache) +static inline size_t kasan_metadata_size(struct kmem_cache *cache, + bool in_object) { return 0; } diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c index d8b5590f9484..b076f597a378 100644 --- a/mm/kasan/generic.c +++ b/mm/kasan/generic.c @@ -450,15 +450,22 @@ void kasan_init_object_meta(struct kmem_cache *cache, const void *object) __memset(alloc_meta, 0, sizeof(*alloc_meta)); } -size_t kasan_metadata_size(struct kmem_cache *cache) +size_t kasan_metadata_size(struct kmem_cache *cache, bool in_object) { + struct kasan_cache *info = &cache->kasan_info; + if (!kasan_requires_meta()) return 0; - return (cache->kasan_info.alloc_meta_offset ? - sizeof(struct kasan_alloc_meta) : 0) + - ((cache->kasan_info.free_meta_offset && - cache->kasan_info.free_meta_offset != KASAN_NO_FREE_META) ? - sizeof(struct kasan_free_meta) : 0); + + if (in_object) + return (info->free_meta_offset ? + 0 : sizeof(struct kasan_free_meta)); + else + return (info->alloc_meta_offset ? + sizeof(struct kasan_alloc_meta) : 0) + + ((info->free_meta_offset && + info->free_meta_offset != KASAN_NO_FREE_META) ? + sizeof(struct kasan_free_meta) : 0); } static void __kasan_record_aux_stack(void *addr, bool can_alloc) diff --git a/mm/slub.c b/mm/slub.c index 17292c2d3eee..adff7553b54e 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -910,7 +910,7 @@ static void print_trailer(struct kmem_cache *s, struct slab *slab, u8 *p) if (slub_debug_orig_size(s)) off += sizeof(unsigned int); - off += kasan_metadata_size(s); + off += kasan_metadata_size(s, false); if (off != size_from_object(s)) /* Beginning of the filler is the free pointer */ @@ -1070,7 +1070,7 @@ static int check_pad_bytes(struct kmem_cache *s, struct slab *slab, u8 *p) off += sizeof(unsigned int); } - off += kasan_metadata_size(s); + off += kasan_metadata_size(s, false); if (size_from_object(s) == off) return 1; From patchwork Fri Oct 21 03:24:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 6497 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp459465wrr; Thu, 20 Oct 2022 20:27:03 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5FCYJvOrn+0ZwSPw0OGaCRUsC64iMlVo/lmOfPqMfglW+ZV6wjsUPpZxqr14DFTFUoAzvM X-Received: by 2002:a05:6a00:23d6:b0:565:84d7:64c0 with SMTP id g22-20020a056a0023d600b0056584d764c0mr17097751pfc.43.1666322823388; Thu, 20 Oct 2022 20:27:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666322823; cv=none; d=google.com; s=arc-20160816; b=aTqMw/T0ZNHkzbHV/JZ+Jcm1xkPGQ8PWKIRm/dv3OltOXuCU1ppeEzpronTD2mWG8v Gm3rejwlr0NKLikLVT5+6YkBOJyoiZlQ5h7b23a5zxK2sxA78cxYCNESFuSmERQRGL1i aQW+XNo6mnfV8NogzBkeFGhcNd8VK9o3dI2Ojfbyz/mmWfYBFQdWYokR0fel14mvRqd7 R8ufPWexFr39QvoDIaDWVbFm14lGdRqBxrRzHMLaX5CBmdMqdUH7W3dfnEFlH4rl049i RxnG97AN3eBO/6yxI451ctHOd89es0KQdcGzJV0c7ZMN7m7gRXk7/oEtnlljKT9iMTyU CV+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ms3Ytik3W/RJebwRdrY+iMC5yNLhiRgPO9DIkBKR5Fk=; b=JDIgo4EFI4VZMFyS2VwHu/jqp/kQp+1KEHAyDAxh79sWgQcQzhMEXWNGq2f42EYBRE CzXsMRWg/2ZHcrUbeN7r39ZCxctzGDPvo7weYGTT/aMyoZ5oApTi6zozOmZQaI8DhpsN k5jO+rJzhWAbPMWW5644AZV6kIiqvtwwzwrP7yOI9A0U6lFjlhR0aoQOX9N5CTn1puUm t3MrYS3M3KiDewUd0KPo0e+gPUXgp5dMPdEjs4CENQ+/it8/qlx+bFV5j488R0COws97 TOaSE3KDSGn9XY/wKOznzaGvzJYDKcDP+Bf28wKFND7FXjcAWY4meOxL7FI1zIobxT20 ZWpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ToqI//OF"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a6-20020a170902ecc600b0017829e27195si28752007plh.521.2022.10.20.20.26.49; Thu, 20 Oct 2022 20:27:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ToqI//OF"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230076AbiJUDYu (ORCPT + 99 others); Thu, 20 Oct 2022 23:24:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230015AbiJUDYg (ORCPT ); Thu, 20 Oct 2022 23:24:36 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3D5B5F8F for ; Thu, 20 Oct 2022 20:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666322669; x=1697858669; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BgwnaduZY7Uty+d/aSigQJByRP8rJXh8ABZquZbtWNQ=; b=ToqI//OFeJx8MV3ZZCMBrm/efbVxESRN/VoMo4wz3DtcgwRmStnGjzEj 5UjIbTQmIMm05k7LcMSWpNCBkBwepfopb+chJ9GEV8wtbiG4eQHtlzYRm 1DoQNgsI0VqJVtoNQS1VnIEVk02gJE58uAd0pTMYJ216/L4snN9UPEQ8C GTnyX2xe0Y3FB1rpTWy2HJ3afcsW2wpxOM35Rhd2owPF77pKs3DUHiY9d H7dgrkNH6LxZ6izx2mzNrSqt/BSQ/AnuLJta/LtIN4sMEW7FVyoMVyDHV UYhqAng+jf5fw35I911fPfJAejZRkMakdmqkAXZKUJLPhiyK3Lr9/ll3+ g==; X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="333471620" X-IronPort-AV: E=Sophos;i="5.95,200,1661842800"; d="scan'208";a="333471620" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2022 20:24:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="719459612" X-IronPort-AV: E=Sophos;i="5.95,200,1661842800"; d="scan'208";a="719459612" Received: from feng-clx.sh.intel.com ([10.238.200.228]) by FMSMGA003.fm.intel.com with ESMTP; 20 Oct 2022 20:24:19 -0700 From: Feng Tang To: Andrew Morton , Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dmitry Vyukov , Andrey Konovalov , Kees Cook Cc: Dave Hansen , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Feng Tang Subject: [PATCH v7 3/3] mm/slub: extend redzone check to extra allocated kmalloc space than requested Date: Fri, 21 Oct 2022 11:24:05 +0800 Message-Id: <20221021032405.1825078-4-feng.tang@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221021032405.1825078-1-feng.tang@intel.com> References: <20221021032405.1825078-1-feng.tang@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747266120964709332?= X-GMAIL-MSGID: =?utf-8?q?1747266120964709332?= kmalloc will round up the request size to a fixed size (mostly power of 2), so there could be a extra space than what is requested, whose size is the actual buffer size minus original request size. To better detect out of bound access or abuse of this space, add redzone sanity check for it. In current kernel, some kmalloc user already knows the existence of the space and utilizes it after calling 'ksize()' to know the real size of the allocated buffer. So we skip the sanity check for objects which have been called with ksize(), as treating them as legitimate users. In some cases, the free pointer could be saved inside the latter part of object data area, which may overlap the redzone part(for small sizes of kmalloc objects). As suggested by Hyeonggon Yoo, force the free pointer to be in meta data area when kmalloc redzone debug is enabled, to make all kmalloc objects covered by redzone check. Suggested-by: Vlastimil Babka Signed-off-by: Feng Tang Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by: Feng Tang Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> --- mm/slab.h | 4 ++++ mm/slab_common.c | 4 ++++ mm/slub.c | 51 ++++++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 55 insertions(+), 4 deletions(-) diff --git a/mm/slab.h b/mm/slab.h index 8b4ee02fc14a..1dd773afd0c4 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -885,4 +885,8 @@ void __check_heap_object(const void *ptr, unsigned long n, } #endif +#ifdef CONFIG_SLUB_DEBUG +void skip_orig_size_check(struct kmem_cache *s, const void *object); +#endif + #endif /* MM_SLAB_H */ diff --git a/mm/slab_common.c b/mm/slab_common.c index 33b1886b06eb..0bb4625f10a2 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1037,6 +1037,10 @@ size_t __ksize(const void *object) return folio_size(folio); } +#ifdef CONFIG_SLUB_DEBUG + skip_orig_size_check(folio_slab(folio)->slab_cache, object); +#endif + return slab_ksize(folio_slab(folio)->slab_cache); } diff --git a/mm/slub.c b/mm/slub.c index adff7553b54e..76581da6b9df 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -829,6 +829,17 @@ static inline void set_orig_size(struct kmem_cache *s, if (!slub_debug_orig_size(s)) return; +#ifdef CONFIG_KASAN_GENERIC + /* + * KASAN could save its free meta data in object's data area at + * offset 0, if the size is larger than 'orig_size', it will + * overlap the data redzone in [orig_size+1, object_size], and + * the check should be skipped. + */ + if (kasan_metadata_size(s, true) > orig_size) + orig_size = s->object_size; +#endif + p += get_info_end(s); p += sizeof(struct track) * 2; @@ -848,6 +859,11 @@ static inline unsigned int get_orig_size(struct kmem_cache *s, void *object) return *(unsigned int *)p; } +void skip_orig_size_check(struct kmem_cache *s, const void *object) +{ + set_orig_size(s, (void *)object, s->object_size); +} + static void slab_bug(struct kmem_cache *s, char *fmt, ...) { struct va_format vaf; @@ -966,13 +982,27 @@ static __printf(3, 4) void slab_err(struct kmem_cache *s, struct slab *slab, static void init_object(struct kmem_cache *s, void *object, u8 val) { u8 *p = kasan_reset_tag(object); + unsigned int orig_size = s->object_size; - if (s->flags & SLAB_RED_ZONE) + if (s->flags & SLAB_RED_ZONE) { memset(p - s->red_left_pad, val, s->red_left_pad); + if (slub_debug_orig_size(s) && val == SLUB_RED_ACTIVE) { + orig_size = get_orig_size(s, object); + + /* + * Redzone the extra allocated space by kmalloc + * than requested. + */ + if (orig_size < s->object_size) + memset(p + orig_size, val, + s->object_size - orig_size); + } + } + if (s->flags & __OBJECT_POISON) { - memset(p, POISON_FREE, s->object_size - 1); - p[s->object_size - 1] = POISON_END; + memset(p, POISON_FREE, orig_size - 1); + p[orig_size - 1] = POISON_END; } if (s->flags & SLAB_RED_ZONE) @@ -1120,6 +1150,7 @@ static int check_object(struct kmem_cache *s, struct slab *slab, { u8 *p = object; u8 *endobject = object + s->object_size; + unsigned int orig_size; if (s->flags & SLAB_RED_ZONE) { if (!check_bytes_and_report(s, slab, object, "Left Redzone", @@ -1129,6 +1160,17 @@ static int check_object(struct kmem_cache *s, struct slab *slab, if (!check_bytes_and_report(s, slab, object, "Right Redzone", endobject, val, s->inuse - s->object_size)) return 0; + + if (slub_debug_orig_size(s) && val == SLUB_RED_ACTIVE) { + orig_size = get_orig_size(s, object); + + if (s->object_size > orig_size && + !check_bytes_and_report(s, slab, object, + "kmalloc Redzone", p + orig_size, + val, s->object_size - orig_size)) { + return 0; + } + } } else { if ((s->flags & SLAB_POISON) && s->object_size < s->inuse) { check_bytes_and_report(s, slab, p, "Alignment padding", @@ -4206,7 +4248,8 @@ static int calculate_sizes(struct kmem_cache *s) */ s->inuse = size; - if ((flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON)) || + if (slub_debug_orig_size(s) || + (flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON)) || ((flags & SLAB_RED_ZONE) && s->object_size < sizeof(void *)) || s->ctor) { /*