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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3130C5479D for ; Mon, 9 Jan 2023 06:51:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 66B9F8E0005; Mon, 9 Jan 2023 01:51:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 61BF38E0001; Mon, 9 Jan 2023 01:51:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E3898E0005; Mon, 9 Jan 2023 01:51:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3EE1F8E0001 for ; Mon, 9 Jan 2023 01:51:20 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 00D8B1C43AB for ; Mon, 9 Jan 2023 06:51:19 +0000 (UTC) X-FDA: 80334339120.10.EF65D0B Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf01.hostedemail.com (Postfix) with ESMTP id 590C840014 for ; Mon, 9 Jan 2023 06:51:18 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OyMUf+5B; spf=pass (imf01.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673247078; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8fHjJ5mqa9cPGpS5KD+GC/eZ7abKkX/dkmk/DvDpfNA=; b=U7AKVlR+i/eSSQZApdBu8o/hm+r+E4uav34ZpJzyZZj0tt/mrEB9IS+82TkMTmu7XD8gD2 x6pmpHYC6NTB1K6LHbAbcis083LTznW9pdfq2IYwEhAuL8Cm14MTUh0RWLay7gPe8PtTwo r1BdiCOJA6x22RQjyXyVhlbmsAo2efk= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OyMUf+5B; spf=pass (imf01.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673247078; a=rsa-sha256; cv=none; b=oY0PpkzioR2igmC75Nlp4i979XtOGo5ZVLt3F41QPlUMRm/qhW3EfFKTndvZ7U4xkFIh7B B263X/vdSDS++qyPxuk+xVViDMzKfiFrYMKuzBoLot+qztgRxkxWR4k4enPOOCD4mlIMyx IC/DIFp1yUtKQ3Aregwn7PZWxdY7e7g= Received: by mail-lf1-f53.google.com with SMTP id f34so11478750lfv.10 for ; Sun, 08 Jan 2023 22:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8fHjJ5mqa9cPGpS5KD+GC/eZ7abKkX/dkmk/DvDpfNA=; b=OyMUf+5B6frZZs4hQkljDvf/Xom1i0Hqd9XJHQkHyv7eihmEw1hjihNs3D99WNWYdr z9hevlf2PG4glj9VEoG+tDPk2ZYWsPeICavudYQWLYiTye6iTYirV+zuwBaHqWXWGeHQ ioBbj5QAhnOumJ6vGSvi90hV9Z9Ns8tD50zqOfwwZC2qgL+8cpoQ+sNQCW6bq+wJiCEu 3+RHv073gwOCssDoZeVPmWmk2a4LhYJOSejGG1NRazdFDx6z6MoQuP1NFKSwnqPI93LM xHGIK/3IDfUZ2L6jP8bddwAIfVCkmPe458adq7vFG6hlA/WlyRNAzQzc1JIrIZJNMPsi KVIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8fHjJ5mqa9cPGpS5KD+GC/eZ7abKkX/dkmk/DvDpfNA=; b=Rgcl9pc/Hqy9AdMturFoYffUcs4Brb9BCXEEUPMR2pBFvuqvz7VfTZKNnR67a8RZsz JKd0TB+qWgGAOFdRLK+h8R+g+EGpuk5kHdGmtSffSNRrKEF5Lxv5sCC1czYUn/J1xjwB 1owmWfOgK7w11cKQazi0T6f6cDBqPcdPi5tZVilGM4Kqx/70K3soTSLHo3Uvy64/shCr S59ghXdrvEmA2xb9t8ViJrCoZnrz7ZbB2VUf3+4ZIMwZ2RF/I0opKX8KevXcwQktofls Ftr5MEfWeORqFQ/FyPi50Cn20Ml4/uR00WXLIfQubHmFbWqgd/30DO4AJ8eXFTmEZARh jrKw== X-Gm-Message-State: AFqh2kpCG9Ow0Mr3R8dbDlfwc3rSALmG0Gbz8sCI0Dr4ysELW7h2fsLL v6Ku0EZHwwm9/66qIwAYQZVerG14Oi+0dfnKarHwNg== X-Google-Smtp-Source: AMrXdXuVTKk1ETT5Fbh/qF7a1Xz+KlgI8zhmIxManlxld7viGQP54p+iATQQMAy1889O+cOC7C/yKyGSSxzC7jPT3r8= X-Received: by 2002:a05:6512:12c4:b0:4a2:676e:cf60 with SMTP id p4-20020a05651212c400b004a2676ecf60mr2640163lfg.624.1673247076285; Sun, 08 Jan 2023 22:51:16 -0800 (PST) MIME-Version: 1.0 References: <20230103075603.12294-1-Kuan-Ying.Lee@mediatek.com> In-Reply-To: <20230103075603.12294-1-Kuan-Ying.Lee@mediatek.com> From: Dmitry Vyukov Date: Mon, 9 Jan 2023 07:51:04 +0100 Message-ID: Subject: Re: [PATCH] kasan: infer the requested size by scanning shadow memory To: Kuan-Ying Lee Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Vincenzo Frascino , Andrew Morton , Matthias Brugger , chinwen.chang@mediatek.com, qun-wei.lin@mediatek.com, kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 590C840014 X-Stat-Signature: wj4o7s9771yz8wmu6r9b4ckqmza91w6q X-Rspam-User: X-HE-Tag: 1673247078-218348 X-HE-Meta: U2FsdGVkX18nxKSvTn/aV2X7p4VH79QhEAF9cfvfOzcNwPAfz9nxLthBPxtdyK4W+H5GPo6xd8ID7pztcWt18ANYbGP4dtOjBlJ9ClBBdh25f6O/2ciB35KQfEE2pCWfJep0E5AD50+WgP8SPCqUBbFbbuHQt3AyyGUa9ZXEM+J9qwR+qYOBddHXTf+82Br+bVcsvQebUPDUGJj9mSFYXMLc/Wc+37tGaHNi2M+7HkffegzCnRlb/ZUg65j6DtZwF1YUd5lgd1HmCgnquTfwLPgJhCkWDZHvZUUQpJ3fVJaN9Ltpy0OCctFBs3jgHubYGp+/IHqDjpeNcmOuzMokl4yuB3D+oUVSAPQeuPYe5gIJMLFZGnPwCUYNnl8kdKRUUXkhLNq6z3NhV/EDH8vqs6bBsKUya+ntRbNRsYjxABnCgMTeYvs3GhSieUwimgz1xgo0cjNwhbn066jrsM8x5gkK+pTcfRrB3QfTBt72hdycGQQtl2kmJzQfB3yA6G9S5aLREhcl+7Sq5WGFkZ5Ob+fw8a+Ynm2vF7C8q33AxQZ5i0T887s8eBhF5ERWpHvLl8jcz75q6tlEP3N5r+IybW97p3X8IvLdOJZ8iWqSyq/4FOY6VWDMFbYsZ5QxTM9thCJrVz+t1WjCVrIk/2ZKjKNaT4NYD3yHF175ljIjMzMDZ76Gu5aE5bv28C48rJwG4SgBdEoyUD99TAmbOjPT8wP7HUNIw9hhUzy9c9DNPAqw8YbXF4JIw1JClvLThsTFjZLpO40CwNV02GwIXASmj4sKHZnnh9CwMBPifb6X4AG5iU2GQmIf0h48KU+t6cMH0naPrrHdUxfMvNVck/Ujp3IkynQBy1J4hxQoWW2nKAnAW2AUCv/+FaBP/YoQfLYnEm5rhsr73zNHsT+mMZpi449JNnTfSSasnXreji8+Q2+HkpccGjTdlLu9GPzRplsZoTVpDkau+2F2uX2Jf42 2d8zZAVo 0PdqJwFEmcjsuxlOONJcWzGJFTyur1/0vbpTe3Qj8VsY5XxkxLcmGIr+P8XqnLbfUa9d8aS1jHsgVwzMW1MGkJ41UEA== 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 Tue, 3 Jan 2023 at 08:56, 'Kuan-Ying Lee' via kasan-dev wrote: > > We scan the shadow memory to infer the requested size instead of > printing cache->object_size directly. > > This patch will fix the confusing generic kasan report like below. [1] > Report shows "cache kmalloc-192 of size 192", but user > actually kmalloc(184). > > ================================================================== > BUG: KASAN: slab-out-of-bounds in _find_next_bit+0x143/0x160 lib/find_bit.c:109 > Read of size 8 at addr ffff8880175766b8 by task kworker/1:1/26 > ... > The buggy address belongs to the object at ffff888017576600 > which belongs to the cache kmalloc-192 of size 192 > The buggy address is located 184 bytes inside of > 192-byte region [ffff888017576600, ffff8880175766c0) > ... > Memory state around the buggy address: > ffff888017576580: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc > ffff888017576600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >ffff888017576680: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc > ^ > ffff888017576700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff888017576780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ================================================================== > > After this patch, report will show "cache kmalloc-192 of size 184". > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216457 [1] > > Signed-off-by: Kuan-Ying Lee > --- > mm/kasan/kasan.h | 5 +++++ > mm/kasan/report.c | 3 ++- > mm/kasan/report_generic.c | 18 ++++++++++++++++++ > 3 files changed, 25 insertions(+), 1 deletion(-) > > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h > index 32413f22aa82..7bb627d21580 100644 > --- a/mm/kasan/kasan.h > +++ b/mm/kasan/kasan.h > @@ -340,8 +340,13 @@ static inline void kasan_print_address_stack_frame(const void *addr) { } > > #ifdef CONFIG_KASAN_GENERIC > void kasan_print_aux_stacks(struct kmem_cache *cache, const void *object); > +int kasan_get_alloc_size(void *object_addr, struct kmem_cache *cache); > #else > static inline void kasan_print_aux_stacks(struct kmem_cache *cache, const void *object) { } > +static inline int kasan_get_alloc_size(void *object_addr, struct kmem_cache *cache) > +{ > + return cache->object_size; > +} > #endif > > bool kasan_report(unsigned long addr, size_t size, > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > index 1d02757e90a3..6de454bb2cad 100644 > --- a/mm/kasan/report.c > +++ b/mm/kasan/report.c > @@ -236,12 +236,13 @@ static void describe_object_addr(const void *addr, struct kmem_cache *cache, > { > unsigned long access_addr = (unsigned long)addr; > unsigned long object_addr = (unsigned long)object; > + int real_size = kasan_get_alloc_size((void *)object_addr, cache); > const char *rel_type; > int rel_bytes; > > pr_err("The buggy address belongs to the object at %px\n" > " which belongs to the cache %s of size %d\n", > - object, cache->name, cache->object_size); > + object, cache->name, real_size); > > if (access_addr < object_addr) { > rel_type = "to the left"; > diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c > index 043c94b04605..01b38e459352 100644 > --- a/mm/kasan/report_generic.c > +++ b/mm/kasan/report_generic.c > @@ -43,6 +43,24 @@ void *kasan_find_first_bad_addr(void *addr, size_t size) > return p; > } > > +int kasan_get_alloc_size(void *addr, struct kmem_cache *cache) > +{ > + int size = 0; > + u8 *shadow = (u8 *)kasan_mem_to_shadow(addr); > + > + while (size < cache->object_size) { > + if (*shadow == 0) > + size += KASAN_GRANULE_SIZE; > + else if (*shadow >= 1 && *shadow <= KASAN_GRANULE_SIZE - 1) > + size += *shadow; > + else > + return size; > + shadow++; This only works for out-of-bounds reports, but I don't see any checks for report type. Won't this break reporting for all other report types? I would also print the cache name anyway. Sometimes reports are perplexing and/or this logic may return a wrong result for some reason. The total object size may be useful to understand harder cases. > + } > + > + return cache->object_size; > +} > + > static const char *get_shadow_bug_type(struct kasan_report_info *info) > { > const char *bug_type = "unknown-crash";