From patchwork Wed Nov 22 23:12:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: andrey.konovalov@linux.dev X-Patchwork-Id: 168608 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:6f03:b0:164:83eb:24d7 with SMTP id r3csp1562066rwn; Wed, 22 Nov 2023 15:12:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IE9qHWHTXh+SOj652lBod76iZ2KL5yaB7wGYbIPHLnfcPN3k666sc+rKBvx9pA8zvy9T2jP X-Received: by 2002:a17:90b:4a4e:b0:280:cd15:9684 with SMTP id lb14-20020a17090b4a4e00b00280cd159684mr4818954pjb.37.1700694743888; Wed, 22 Nov 2023 15:12:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700694743; cv=none; d=google.com; s=arc-20160816; b=TIGipceGswOhGDD+ASuBsTmEX+RxYAr1N3RSVQjwPtoy9NsCh6jzTYqCzncDgi9aO8 jt/RSRCidhWZyuCiyTkl6PJ+hlvPPxAJxsfmOgoI2+VUMyGQzfGQGHno+we0FVOR/vxM TcE2UjVnycqtfln7Hv5cfgli4cydbUPxsbT4I99XhLYMnm3Yy/MH/smSrxZEqzM1EN9m wu6sW0fn3AdR8PKqH8aACVTyMY437v1KNQyqtQmrCIypwpdNmiyrIg+pZE+h9h9CbTAv 6Qtrq38vAKIp+wZZilfKw8q3taXqbGcM/n5hkdCDR/FXaCcGm4lSpCHpNmTsBnnQGjG1 GoMA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=uNmdlwYGwAMCb5jza2UGKjePd3PtCVqVMGoJzVDye+g=; fh=fOg1Tf0zNjDt2cuVJIoiwDMJeeeK+fpyehPH3RFMkTQ=; b=FDwdIIdC+IkQU1M4UEdgB6x+MyQr+wg1y31N5hY2X4pHf3rqGXEIVhNbdMlNf40Mfh kvdyVcRxtsyNTwiE3ujmHnQSb5WPm8rLjWNLCYAHa6uwvNsv++A54UAHh45pusmH4b3O Sj+C55wZ7o2ujc3wN7L5NSMiL9v+/C8g/sARaCVV6gkOT2YlH2XHSoFT8lwnzs+ODpp0 N4qFVQCavwmJrMNwb6eX+8SKRfq7NGmJfszyjcsiIEs74aqpmUkNEHKH6NJYW6zzxjH0 fzQ9PRkyvU/U7so0eDLfW0lZvEoIaz2FJ+5IwhpCker25yU5mm/6HR9mP3E3fVbzPs2K g3dw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=EbjD+Kjt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id jx4-20020a17090b46c400b002839e721d0dsi90493pjb.77.2023.11.22.15.12.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Nov 2023 15:12:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=EbjD+Kjt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 27096804C564; Wed, 22 Nov 2023 15:12:15 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233574AbjKVXMP (ORCPT + 99 others); Wed, 22 Nov 2023 18:12:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229879AbjKVXMO (ORCPT ); Wed, 22 Nov 2023 18:12:14 -0500 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7614101 for ; Wed, 22 Nov 2023 15:12:09 -0800 (PST) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1700694727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=uNmdlwYGwAMCb5jza2UGKjePd3PtCVqVMGoJzVDye+g=; b=EbjD+KjtUReYpy3VEP2zh1PWDPdocfuDXn//2UykrrShxpEvbz8Lt2fOjSTIqAaqQQSP7V CYH/tF+RfK9UBYjQWzumEnZ/lRQqdOcxNIy6bxBqR8zc55i8kVhf3qeEOvvYkfiviv7XtT J/+WXzYfqAyKcZ3HAi6QMawrfjd1sEU= From: andrey.konovalov@linux.dev To: Andrew Morton Cc: Andrey Konovalov , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Oscar Salvador , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Feng Tang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Subject: [PATCH mm] slub, kasan: improve interaction of KASAN and slub_debug poisoning Date: Thu, 23 Nov 2023 00:12:02 +0100 Message-Id: <20231122231202.121277-1-andrey.konovalov@linux.dev> MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE 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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 22 Nov 2023 15:12:15 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783307691617299074 X-GMAIL-MSGID: 1783307691617299074 From: Andrey Konovalov When both KASAN and slub_debug are enabled, when a free object is being prepared in setup_object, slub_debug poisons the object data before KASAN initializes its per-object metadata. Right now, in setup_object, KASAN only initializes the alloc metadata, which is always stored outside of the object. slub_debug is aware of this and it skips poisoning and checking that memory area. However, with the following patch in this series, KASAN also starts initializing its free medata in setup_object. As this metadata might be stored within the object, this initialization might overwrite the slub_debug poisoning. This leads to slub_debug reports. Thus, skip checking slub_debug poisoning of the object data area that overlaps with the in-object KASAN free metadata. Also make slub_debug poisoning of tail kmalloc redzones more precise when KASAN is enabled: slub_debug can still poison and check the tail kmalloc allocation area that comes after the KASAN free metadata. Signed-off-by: Andrey Konovalov Acked-by: Vlastimil Babka --- Andrew, please put this patch right before "kasan: use stack_depot_put for Generic mode". --- mm/slub.c | 41 ++++++++++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 63d281dfacdb..782bd8a6bd34 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -870,20 +870,20 @@ static inline void set_orig_size(struct kmem_cache *s, void *object, unsigned int orig_size) { void *p = kasan_reset_tag(object); + unsigned int kasan_meta_size; 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. + * KASAN can save its free meta data inside of the object at offset 0. + * If this meta data size is larger than 'orig_size', it will overlap + * the data redzone in [orig_size+1, object_size]. Thus, we adjust + * 'orig_size' to be as at least as big as KASAN's meta data. */ - if (kasan_metadata_size(s, true) > orig_size) - orig_size = s->object_size; -#endif + kasan_meta_size = kasan_metadata_size(s, true); + if (kasan_meta_size > orig_size) + orig_size = kasan_meta_size; p += get_info_end(s); p += sizeof(struct track) * 2; @@ -1192,7 +1192,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; + unsigned int orig_size, kasan_meta_size; if (s->flags & SLAB_RED_ZONE) { if (!check_bytes_and_report(s, slab, object, "Left Redzone", @@ -1222,12 +1222,23 @@ static int check_object(struct kmem_cache *s, struct slab *slab, } if (s->flags & SLAB_POISON) { - if (val != SLUB_RED_ACTIVE && (s->flags & __OBJECT_POISON) && - (!check_bytes_and_report(s, slab, p, "Poison", p, - POISON_FREE, s->object_size - 1) || - !check_bytes_and_report(s, slab, p, "End Poison", - p + s->object_size - 1, POISON_END, 1))) - return 0; + if (val != SLUB_RED_ACTIVE && (s->flags & __OBJECT_POISON)) { + /* + * KASAN can save its free meta data inside of the + * object at offset 0. Thus, skip checking the part of + * the redzone that overlaps with the meta data. + */ + kasan_meta_size = kasan_metadata_size(s, true); + if (kasan_meta_size < s->object_size - 1 && + !check_bytes_and_report(s, slab, p, "Poison", + p + kasan_meta_size, POISON_FREE, + s->object_size - kasan_meta_size - 1)) + return 0; + if (kasan_meta_size < s->object_size && + !check_bytes_and_report(s, slab, p, "End Poison", + p + s->object_size - 1, POISON_END, 1)) + return 0; + } /* * check_pad_bytes cleans up on its own. */