From mboxrd@z Thu Jan 1 00:00:00 1970 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2870DC433F5 for ; Fri, 1 Oct 2021 10:31:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B442C61A7B for ; Fri, 1 Oct 2021 10:31:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B442C61A7B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C524E9400FC; Fri, 1 Oct 2021 06:31:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BDAEE9400E4; Fri, 1 Oct 2021 06:31:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A54439400FC; Fri, 1 Oct 2021 06:31:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 923059400E4 for ; Fri, 1 Oct 2021 06:31:00 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4AD323260E for ; Fri, 1 Oct 2021 10:31:00 +0000 (UTC) X-FDA: 78647500680.30.C888E11 Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com [209.85.161.42]) by imf28.hostedemail.com (Postfix) with ESMTP id 043079000E3D for ; Fri, 1 Oct 2021 10:30:59 +0000 (UTC) Received: by mail-oo1-f42.google.com with SMTP id e19-20020a4a7353000000b002b5a2c0d2b8so2746831oof.3 for ; Fri, 01 Oct 2021 03:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8UnM6fWprDP/p4IMmb85dmfiw4okGcebGCdS4L7uqiY=; b=PypTI49BIXrd7YfVzyBx3BuNZ9XRgaWYoOW7T4Z6fPlr5GaE9BrvhhEenNY1TkRyL8 o2PlvsmZLHWH6ygyq4u30gapPB/J1vr9H1KNyIuSMLVE8Q6I8nCPzHzyTU2aJFPiRh4a 14hKLJX6nEItjU+4Ys47YcFaz5CF5zMbzHUY6vhIuBfUIiVLWlXPSRP9mq8fteM0P+uQ 6fZsPUVOE1RrCArWnUurhfsypt3+c51zaoToC4qiFmNppU7bmHidLyG2VRaNmHCJMdeu gde9MiYFdY6Am0jbESZ3DuhugiZLYG8skhHuhdPpzRWMot3QGZSeAHvwFSFVjVX/IzZA fbkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8UnM6fWprDP/p4IMmb85dmfiw4okGcebGCdS4L7uqiY=; b=vRYgczUGRB8UmNKzOqsZwqL7fwS6I0auE5L2XOIIDoAic9BTVGK1ejtwa0cT3YpvgF pwhupEtJAJn9JWosvUHQ38IOSaqr6kVd6Hzbap2S9DIX+FpE8NkbjaX3++VL29CLbvL0 5Q4VWTEaut0BQDkgvPT+15HZnEQ0A5i2k9zfr3+joldK6CGtpiEX8G3O0yfzFFXbhPaE XFgcVI1OLRmGVS40y/CZ8zvGZ7t3LUewg+AOuK3QbGVY7AEcJ6cfv9oJPlMf2RnUUZfA 1bTC4C5mtBeq/IElkF+9M8Ue3rO3+ReMXwhOznZlPJaxs/276iiYr5J478eVGVgTTIDW 5HqA== X-Gm-Message-State: AOAM5335c6dqnQ3rhJjaSo2gZ/PFjAhNSl86MWOs4DlZE3LjgX8oXwAr pfbPsI/GUYuI1glK4nr4xh6hcdrJ/0TauwWJTKwx9A== X-Google-Smtp-Source: ABdhPJxwtZAXvTBeaHiHcb09pWND5enhe0cJSwW/tIh2yXN7U0Z9ZBzLIy/s7yq9kHv8b4dRxnX8r19yio4QslKX8BE= X-Received: by 2002:a4a:a6c6:: with SMTP id i6mr8693696oom.73.1633084259052; Fri, 01 Oct 2021 03:30:59 -0700 (PDT) MIME-Version: 1.0 References: <20211001024105.3217339-1-willy@infradead.org> In-Reply-To: <20211001024105.3217339-1-willy@infradead.org> From: Marco Elver Date: Fri, 1 Oct 2021 12:30:47 +0200 Message-ID: Subject: Re: [PATCH] kasan: Fix tag for large allocations when using CONFIG_SLAB To: "Matthew Wilcox (Oracle)" Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 043079000E3D X-Stat-Signature: r4p1e6snzx6nw6f46xsyh61qdza6dsap Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=PypTI49B; spf=pass (imf28.hostedemail.com: domain of elver@google.com designates 209.85.161.42 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1633084259-547352 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: On Fri, 1 Oct 2021 at 04:42, Matthew Wilcox (Oracle) wrote: > If an object is allocated on a tail page of a multi-page slab, kasan > will get the wrong tag because page->s_mem is NULL for tail pages. > I'm not quite sure what the user-visible effect of this might be. > > Fixes: 7f94ffbc4c6a ("kasan: add hooks implementation for tag-based mode") > Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Marco Elver Indeed this looks wrong. I don't know how much this code is even tested, because it depends on CONFIG_KASAN_SW_TAGS && CONFIG_SLAB, and the cache having a constructor or SLAB_TYPESAFE_BY_RCU. HW_TAGS isn't affected because it doesn't work with SLAB. And to run SW_TAGS, one needs an arm64 CPU with TBI. And the instances of KASAN_SW_TAGS I'm aware of use SLUB. With eventual availability of Intel LAM, I expect KASAN_SW_TAGS to become more widely used though, including its SLAB support. > --- > mm/kasan/common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/kasan/common.c b/mm/kasan/common.c > index 2baf121fb8c5..41779ad109cd 100644 > --- a/mm/kasan/common.c > +++ b/mm/kasan/common.c > @@ -298,7 +298,7 @@ static inline u8 assign_tag(struct kmem_cache *cache, > /* For caches that either have a constructor or SLAB_TYPESAFE_BY_RCU: */ > #ifdef CONFIG_SLAB > /* For SLAB assign tags based on the object index in the freelist. */ > - return (u8)obj_to_index(cache, virt_to_page(object), (void *)object); > + return (u8)obj_to_index(cache, virt_to_head_page(object), (void *)object); > #else > /* > * For SLUB assign a random tag during slab creation, otherwise reuse > -- > 2.32.0