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 89D33C3DA7D for ; Wed, 4 Jan 2023 02:01:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1A838E0002; Tue, 3 Jan 2023 21:01:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ECA5C8E0001; Tue, 3 Jan 2023 21:01:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D91D48E0002; Tue, 3 Jan 2023 21:01:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C64748E0001 for ; Tue, 3 Jan 2023 21:01:04 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 97039160C71 for ; Wed, 4 Jan 2023 02:01:04 +0000 (UTC) X-FDA: 80315463648.09.BE1C197 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf15.hostedemail.com (Postfix) with ESMTP id 0EBEDA0009 for ; Wed, 4 Jan 2023 02:01:01 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dIntYs8V; spf=pass (imf15.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672797662; 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=hHeFWn8psj8u8cGp1SABE4QnAQdoZWb4E9tsvr9oCvk=; b=lXcy/MlrS14HJ0oQ3Xgf8cP+HbOcMBlBPJ83r8omPwXb+crAju2RqK2RtiVDYo2rX3RET8 mwg5ZSq1KzIbN2FbxqddKWdzHJG70IH1wN+l2d01EqWKwNG72wkjZ/pq2qswKvH1pyBggl TlyAqIEHD8ECFxkkxkcxLAAvZfr83jg= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dIntYs8V; spf=pass (imf15.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672797662; a=rsa-sha256; cv=none; b=QREP+8wyKYzT3kP2JHjJ6gv/Aj8NT3qLwWlWHLFEFSIlq78qz6j/EXVsd6cj6o2BBIVVNu 57LqJ+a27MLC8ArCkRCpwbevnP2J3ZSpyLjGKyh8APfVpo8NxEJ1ndITyVuFH3JY9mpDI6 So69X2w6jtasMIf3E0kmFgPjI9vKF38= Received: by mail-pj1-f51.google.com with SMTP id n65-20020a17090a2cc700b0021bc5ef7a14so32980979pjd.0 for ; Tue, 03 Jan 2023 18:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=hHeFWn8psj8u8cGp1SABE4QnAQdoZWb4E9tsvr9oCvk=; b=dIntYs8Vf4z/54w86VjYfR8QSrf959Il8mXbiEes8eVzuXfpOrY99hD9Ws5Diw5VwO V0SzFWJI9wBDkn2eynnJ2czga+dwdBwdgkhdNlE73DqxIBjzn/Mtl2JnRp4hxcV5eQdE MdbOPFV+pg2nfORgvucmgCQ3xFIS8SRdbzHhc3O687/EHdUrEyIA4z2W/mfNK/KcUhUt bmDhqo0DefNVGKtkJVd09K3bhjLN2dV31/SibDgzkFZohPuRBEl0WQ06frEwB+XuQPqw r9THHuktVvRdSaB3+gyJLh8hIHoUbpbJn4aHdar/Aov1ZwcW6vNg+XIihS3ps4F+umpZ 1zUg== 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=hHeFWn8psj8u8cGp1SABE4QnAQdoZWb4E9tsvr9oCvk=; b=1n04femcw5jY6bnhTpnxxW7BxpHjlylqq92W/41tO1CfqZwtOXuPaHeDeP8YrRlnuz F6CdZhGJOI8BtDqN9XeJzG1LT5Dt6Q9dMtJkJxoTb9127+FSIzOCGUhq1pdDW5MtYVkz mVrDs7AnhWADaTcFbEpwRqrv89dMcnUE+CqaDK6NTedRzIc45mKBjl9vKTe22mqcRyeb wJMI2sUMx2MHYn8shTO4sxGjz0l2AxXOqAEvAGzRKyQB/oafmsvEcC6imQ9Mhb2fPfn/ +STtK2PLwLAQbzbPiHUqdxsD3nGSFridBQD9tlthngfrbic+R+UJzBCevnuYhTvJ4Bs9 TStg== X-Gm-Message-State: AFqh2krvnf4Km6eJXDA1XF+vPO74IBuFG+XgT+uBTJHgD52n/zUSZxCG xbAoC9xIZr/bplVYvPsphi4WRfNfp+iI1elEnIU= X-Google-Smtp-Source: AMrXdXvPnPHlt5A1dFrqgtpDhVrKF7vmu2xsFbu9mcs9JiohmPnLDZXYOyZJdIqGkvnD1Xw31jEejLRYjG3pjpTLPjw= X-Received: by 2002:a17:903:3287:b0:189:8d8b:9db7 with SMTP id jh7-20020a170903328700b001898d8b9db7mr3112912plb.150.1672797660693; Tue, 03 Jan 2023 18:01:00 -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: Andrey Konovalov Date: Wed, 4 Jan 2023 03:00:49 +0100 Message-ID: Subject: Re: [PATCH] kasan: infer the requested size by scanning shadow memory To: Kuan-Ying Lee Cc: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , 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: rspam07 X-Rspamd-Queue-Id: 0EBEDA0009 X-Rspam-User: X-Stat-Signature: 1tn4m38bci873i13c5uxgffppqdncjic X-HE-Tag: 1672797661-171638 X-HE-Meta: U2FsdGVkX19gok4jZpoC1D03mmN0G9Jxfwhhk0sPK5vWtylmaXJ5tkvIvPF7OyqDulj+Y6WIzZw8pZQGXPkuNJ3YZqfwbjWFI1E0f4kbQvrik2j/+vshxORqDCZ5H40kK4uFB3J4P9+90S5ZPTo+On/UiWEUuLdjmv321n4s1FyQZhJS5F25VmubEu0WS1Jxn55oVh/TiOOwY75vUP5J/NIAyy+ZiXrTOyTYK32vNNtknrlvC/a7TfgTWfFWOClL+cAf20ZJ67jo//UT9S1bT1sfqEpnGeqsWonDGivgTGB3qsPo+hWLeQ6bkbuMO3JsPhLA9pyHnCyR7F8+i8lYJWO10Y3DcmcQQRPY6LHCJuQzRQYzItiMebwADzajKQPpKGEpUj90rdoj1xHzA2GXbyQ9xP78awmehV57zUtujCqoIRC52vbOPdSPKXEcnhDZXcy6GeJOMyvlVBjALiOrMJjaCkZAoL5oFDBM+gfwYIrkV5GFE6+edVtzj6piQA0mW3aPHskz+adHdd4zDap+J9JhB2slX7sfql62AxSew0S88e16gARGXevi8JHA85cq3AVtRagGcH1TAK4BkxBFLidzlgBiK0dP0pmd2f+1+Fus3sIIZSJjSJ1fETfLLYVnQARcNoORlt/Neoc2Jenk1bUaKFgvD3fOZiiGHiAVD8R12SwgJGih6PonvgOK0sc713NK9h6eAVUbdTpOjNf7EfPhEiK0COy/f9JpjYrHHfgcht8ua4Ih7elpRKr/k/bldAog38w2ib+aYEXYvut7OvA/DvmYCb6skqR9smj42BInoVynl/tGh94JxjvuE03znWIVY0vvy2VyHvVnalqa1QeJ7mtSULN824uOsM7UgmJbiO66wz1szGiHKKMBRcyZQVKcjOPpexoau3JYMfAdIjmD1hjfUHAXRASA15Z+K3DNm3SVPLGyCtfB/Jjg/vrBJ5Kc8G3kQI3/Jq+4y9s QrAyS+aa b0Nn9gZgSf0Ep6T6giaFa6EO+KMvkJoXz9NmXLPy9Vlvl857kM6qOoGD5GE5FksnSqGpNiRZCPSskgv8+Fw0A8G4u1bbm//v88nTFxRRwlznMt5NpboQIVww9DE6vshdtGynA X-Bogosity: Ham, tests=bogofilter, spamicity=0.004817, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jan 3, 2023 at 8:56 AM Kuan-Ying Lee 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". I think this introduces more confusion. kmalloc-192 cache doesn't have the size of 184. Let's leave the first two lines as is, and instead change the second two lines to: The buggy address is located 0 bytes to the right of requested 184-byte region [ffff888017576600, ffff8880175766c0) This specifically points out an out-of-bounds access. Note the added "requested". Alternatively, we could say "allocated". > --- 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; Please implement similar shadow/tag walking for the tag-based modes. Even though we can only deduce the requested size with the granularity of 16 bytes, it still makes sense. It makes sense to also use the word "allocated" instead of "requested" for these modes, as the size is not deduced precisely. > --- 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); Please add another field to the mode-specific section of the kasan_report_info structure, fill it in complete_report_info, and use it here. See kasan_find_first_bad_addr as a reference. Thanks for working on this!