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 6A7D3EEAA7F for ; Fri, 15 Sep 2023 01:51:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A1B06B02B8; Thu, 14 Sep 2023 21:51:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84F6B6B02BA; Thu, 14 Sep 2023 21:51:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 717636B02FA; Thu, 14 Sep 2023 21:51:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5D1CA6B02B8 for ; Thu, 14 Sep 2023 21:51:51 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 298FAB3A52 for ; Fri, 15 Sep 2023 01:51:51 +0000 (UTC) X-FDA: 81237155622.28.BB0F8D7 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf11.hostedemail.com (Postfix) with ESMTP id 7410840003 for ; Fri, 15 Sep 2023 01:51:49 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ms+Pf6vV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694742709; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qqLoBm8H6ZiMRz1kerNsf8O/I1x2KB0Fau5qTkJBuRw=; b=pJhfgy2lw2pS2OsgRVhITTISDmYX4AA5EdyaWHbmOmych7kALXuDQR8Xps8gRC8kgvWgd1 2SrO2QKAK5/aYSysCBoOaZD4Ap0hI9Ew6rggtwXZ3aoCd6YK/55Hsr+onBWrc+WhsEFlgX Mji2XjuGQfURj/IloGdr6iqSs3giAKA= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ms+Pf6vV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694742709; a=rsa-sha256; cv=none; b=Ffz/LeqwcheH1+MUp72gkSL72VgrobQ4sII0Aup3tHpf6pUbo8doHkLCgcbtmA9ZdkPlQ2 TJCCdRDdYX2C11Uuvrqa7j95EGydIztjV0qe5vzTpfNKNwli0uXV19zZMFebb3NNPZTZ/T cvEaylhMycL/xlYcxO7MYmz9Av2pe98= Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-26b41112708so1355661a91.3 for ; Thu, 14 Sep 2023 18:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694742708; x=1695347508; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qqLoBm8H6ZiMRz1kerNsf8O/I1x2KB0Fau5qTkJBuRw=; b=Ms+Pf6vVsfN0IQvjhH2GLh6pH3BwM0oT92v5+5cNqS9gq497Ob3ZUhXiJ5dkG4peds qQy6L2Oi82v5S3/AAdOJD5kXV+7Y+7J54M+lRstTpLq9M4DPIiqpHq2//NDgoQdew5zT TXD5Z5faFlK/QDdEI7ItqK+VqNX75WyuuXFI8oQBci4jD+6Yt/pxNlPG8LK7K05vXrpq I0JVW7XTJ9EZxKfl8Hhmk72Hlsi53G3MqWtdrnPCXgameM3LNX2LUxNbCWHj85lW90yu v1HzCQoGK9/Sl0zUBDPiRFvZRv4z7IKXT2VCJkzM9e/XbLLBj+o0xxkeGy3XSy96eUS4 eqeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694742708; x=1695347508; h=content-transfer-encoding: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=qqLoBm8H6ZiMRz1kerNsf8O/I1x2KB0Fau5qTkJBuRw=; b=aHN4nq8qs5YGiD+L4zBMdc3XaVQBfpPK0svDmBacct0URQYmYXJ59yTn4bt99ZLRu6 J+gmfybBpOyoPxEi1Q8JWlU24zJkxfA2yQDIDPRGH3IGvLMrDxxrM65z4de8Oyyjsw5S VeiIezABNehEwhAGIkUD4fvTjyu9NuWX/C31n1u/w8k37tth/8XaGZ+/7yeJ/nphLa7b Yz90934pZmEILBWNGAfXvPEvAf4saUPhzr97ViSqOn02Nhea/vGQER9rFsnruJfqXT+7 a2HH4CwAYTaD6Xrsgq9T1vz9bl7TajsujjGokySDGheoenao0Tws0UXtMuRJkzPOHq/M lfTQ== X-Gm-Message-State: AOJu0Yzo/zoGx9nUJ12INW9ID9Lr9+mSasfYoTewFIN1Ba9A3fbJT0N4 oWKs+rPGAjS4C0x4D/HrMPPKf9lYzHFHsiQG+Sw= X-Google-Smtp-Source: AGHT+IHypl50ozXbVNpyt6MCHdaoxCaRqBl2NAiMm+S4Y/6YOO7S8XoNh0lYeLcNgC9idrJZOsUI38MTb7wkV8Iedjg= X-Received: by 2002:a17:90b:a49:b0:268:60d9:92cc with SMTP id gw9-20020a17090b0a4900b0026860d992ccmr210845pjb.43.1694742708242; Thu, 14 Sep 2023 18:51:48 -0700 (PDT) MIME-Version: 1.0 References: <20230914080833.50026-1-haibo.li@mediatek.com> <20230914112915.81f55863c0450195b4ed604a@linux-foundation.org> In-Reply-To: From: Andrey Konovalov Date: Fri, 15 Sep 2023 03:51:37 +0200 Message-ID: Subject: Re: [PATCH] kasan:fix access invalid shadow address when input is illegal To: Jann Horn , Haibo Li Cc: Andrew Morton , linux-kernel@vger.kernel.org, xiaoming.yu@mediatek.com, Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Vincenzo Frascino , Matthias Brugger , AngeloGioacchino Del Regno , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Mark Rutland Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 7410840003 X-Stat-Signature: qnb48ok6w5oz75es3bf55xer84fcug79 X-Rspam-User: X-HE-Tag: 1694742709-664974 X-HE-Meta: U2FsdGVkX1+FRG+ClYtHF122kUxT8C8FGaBaRmLSh0v/GtUHw4hDcI2rVE9DyLdo0FGXo3hNMv4n8eC+GXfjV8a2UMO3telsh3nbJ4FFzQgDxYokjPJQ84YxYUw/sO4OHzu9VOYDVlm1sDsUTpMnqFrBUmMvuoQF8BsJWLrr/s8s30s+QJQZNZKm6xzDWPEB28gyhJO7weYbgFFBGSut2U/PggiEhSherrFmqpOWOltxZ7JkAErR5MRFJfwOdb+Ju/N3Q+KzWHxDdu1cin6EGBv9W8XBKjd2xTm3YmX0jkH+xyoFqijlN7GkRffVzED+GmGZ5sk9rgUEybNchEUEvhQv4wUf9LFSWfDuvbf0tEpEqLd7U3tj2Wf6Gqho4cxsFiQ4NuBZamqU8/eMbTE3lLjdnG0WDd3ah2gACNfeU0Ew2VR7MvQ2ptv0Gb/kzJ9bU0RuGXZOUaTntAXmmZHUVULuhm35pB2V7o2GK2+27KLun5ozVIDX75sev8LmmJRtLLKosxHS1b9L5UsP7BJ9rFB6vfVL2izygywQk77kS7JonUgxoyxlGYOMkB2L+JhJgygpDnWLHBxDooypu6i005oQfosVooIx/WYgY53DYweW9ka7qz2knfynrxVGw+/Tt6Nzww1a8bVAEwR9l4a8kcpESXe3ce5hvzzz/+JOrzuvsRkBnVt3CKIvQsAmRab0HgII8EREdKut7kkkGq4YGVKnchTLcomx4j1vjqkxcQSRB0nvgxsuRANm4c2TirDsKm7ANv4ZdZNKIYMNDn6GlQl+TbCatgYBU7sdyS0zHKZ1arvjg4XhlVgjkLB3ZHYw1xQT8cJKiEjKO0Iq5TCOGLvdfW2cSPPCvGHwQuHL1AfHYoW7yoz3umVnTvaJ4tB841a8tSUaeGfb3bPRjdItWMRX0Jx2EK76X2jz3tP/xjLOgD+tsK6bSriShjp+CS40Fgq67TYUG99ink5zwTQ BrZ5TNJi kME6tdGHnoogjrHCtw6hkw/kgd2qayMzlj45PQRiIE80eNQ1GRxKgNlVE8+BMCw+TaNkudUKOMiojlB6Yli9Sz2OzeSMtokLQJJqzHEOlxAQuBGM8mEk1c61VJBIfpuQ2YCDB0dOLrJfvDw6xjSQUIizsAGrLFaYAoD84XaFOZ0eDkiLeFEX1MSxVKzbgBCn6lS/X6nbY05fS5YLqH0hR6WP84WZ8D6klbxy1FiCxdgu34j4TWgwz4EVVISa6oL09olcNcz6V4kQI7tivYoMrqGJEMxdHIusfTYiz+0aTXwP02kp8lf0WjyLDrg8LiEaHaQ04oms9UgCQuOGpPWyJG3tRLUu8+divpj8SpHU6cVJS+v318XnMRqxiCjI/CyFPrxvnYP0chKl4NnvQz0bi8/nGFlwiLgOQ9f/btaYEI8VXta/5iXzLR+81LrgU0u7qXEHeIiComtZZ2F2iACIa2RrPIRgxCQuKJYwcdt8k7gjMoC4= 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 Thu, Sep 14, 2023 at 10:41=E2=80=AFPM Jann Horn wrote= : > > > Accessing unmapped memory with KASAN always led to a crash when > > checking shadow memory. This was reported/discussed before. To improve > > crash reporting for this case, Jann added kasan_non_canonical_hook and > > Mark integrated it into arm64. But AFAIU, for some reason, it stopped > > working. > > > > Instead of this patch, we need to figure out why > > kasan_non_canonical_hook stopped working and fix it. > > > > This approach taken by this patch won't work for shadow checks added > > by compiler instrumentation. It only covers explicitly checked > > accesses, such as via memcpy, etc. > > FWIW, AFAICS kasan_non_canonical_hook() currently only does anything > under CONFIG_KASAN_INLINE; Ah, right. I was thinking about the inline mode, but the patch refers to the issue with the outline mode. However, I just checked kasan_non_canonical_hook for SW_TAGS with the inline mode: it does not work when accessing 0x42ffffb80aaaaaaa, the addr < KASAN_SHADOW_OFFSET check fails. It appears there's something unusual about how instrumentation calculates the shadow address. I didn't investigate further yet. > I think the idea when I added that was that > it assumes that when KASAN checks an access in out-of-line > instrumentation or a slowpath, it will do the required checks to avoid > this kind of fault? Ah, no, KASAN doesn't do it. However, I suppose we could add what the original patch proposes for the outline mode. For the inline mode, it seems to be pointless, as most access checks happen though the compiler inserted code anyway. I also wonder how much slowdown this patch will introduce. Haibo, could you check how much slower the kernel becomes with your patch? If possible, with all GENERIC/SW_TAGS and INLINE/OUTLINE combinations. If the slowdown is large, we can just make kasan_non_canonical_hook work for both modes (and fix it for SW_TAGS).