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 1A260C64ED6 for ; Mon, 27 Feb 2023 02:14:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 682F66B0072; Sun, 26 Feb 2023 21:14:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 60AAD6B0073; Sun, 26 Feb 2023 21:14:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AC3D6B0074; Sun, 26 Feb 2023 21:14:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 34EF66B0072 for ; Sun, 26 Feb 2023 21:14:00 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E7BC7402B4 for ; Mon, 27 Feb 2023 02:13:59 +0000 (UTC) X-FDA: 80511451398.21.FFDF18A Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf22.hostedemail.com (Postfix) with ESMTP id 2E1D0C000D for ; Mon, 27 Feb 2023 02:13:57 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QaqU4DEa; spf=pass (imf22.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.214.179 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=1677464038; 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=EL7MuJSDTGevv/5NshB4YJDYr1z5Pg/OiTSz3dYlut0=; b=uXzHRI5AXqus0iiR5w9XpuKj5peq/zQ2etPypVAKrE1RtTNda1Nuw0AT1hWnsh1XOocjS1 5n47YOxeJCnXY4bbLPLviLKrFGAuicqbwA+HbGJBYILGdhJDQFpDBRbx9fbOM3fPRng3BM tKp8NiMgVun5JmYYk/QDEKsR+Zxwp9c= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QaqU4DEa; spf=pass (imf22.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.214.179 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=1677464038; a=rsa-sha256; cv=none; b=e3Nh0cBoJY90PIv0bEkqQM4kCbkPfdNV/8nFJvQJRZQbXJRNw7G/38ECa1QdWRNPYxG9bI 3P8JaoI4Ohl2JRx0ayrAe0MJqyFQCGYs6H1lKhB05oq5p7jAUHcpXS5fgjaj3oFldxAOZa VJRw7uTQUMrTv4tNeBElcl2Pw4gprsE= Received: by mail-pl1-f179.google.com with SMTP id u5so1821754plq.7 for ; Sun, 26 Feb 2023 18:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=EL7MuJSDTGevv/5NshB4YJDYr1z5Pg/OiTSz3dYlut0=; b=QaqU4DEaPYkI3jbBEvsdldSOgP64djE29YpRXOkqDO9Rny8cCSqM3/pxl6wwAxHy7h cxoDKUQlJxVG+Ihl6FApuki1fJY+F4/qagDr5CCYmEkwpHnThEJ+uoWRnCaoVYXgYMie zVGSy2SPY2vXmtclQ0U4+GYrh5wW5G9Nlzsdl/VxpuCMh2qhKCGY8d/BpDo7oqVnTF4c ocfFEHvI+wdd6cDqBoaBRZbRqVmBLXFnhyTX1D/kBsckewx4RxptmGErH0oJtK+aYXkV YyNi3DPCSvQ0GuyOpiJsk8TILWStkJYUgP8sLDRob0/IMVUlu1WLcHu4W8FQkA49KwX3 QDJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=EL7MuJSDTGevv/5NshB4YJDYr1z5Pg/OiTSz3dYlut0=; b=Kjc27IyN8PKAmkS6LzfMn00EGkQn4J+mNxVIDveoTKMZWZ4hSLYjKAJQFN3pfem0Lx 7tSpTwTr+p3pIf/2qkMfoiqs/Cjq5GcC7qZT/I3fH+c4HEwOqbdgqhhviQXfKUH9mdJx KlAWbmhQmiUkgGB4eatopjNlE+2m5VMP4E4FaOtLXjb5pnSjPfq8wf3wyc87HKAUYfa1 96qDVPqQCpoJBVxwkAyLHPUeLVB488VZg56fihcCnU5siM20RxZWtfokfyR/nIRod08q ucWjZMBIMx6fFuQ68ejxpVxiZLMOdenvQM17OZh1lT1OdSKsjrIFeVhE7B6zzezCogF6 yAMA== X-Gm-Message-State: AO0yUKU4KiYn/+kirRbvjUcTXM5ixRZw63TLa05t8eLaCjmK22lk3jzY MnK3KWore988TsqSH/Ov1VI2yUJpJ53uymvkw8w= X-Google-Smtp-Source: AK7set/0s/lvC/FcPoyrtLQpsWGAGqLg6Is1B0ZyjonRu58vFYRpXwwHAkvSAGjzbIn0r2RBb5JbAQaKQPHNAyhEgeM= X-Received: by 2002:a17:90a:17ec:b0:237:30ef:e252 with SMTP id q99-20020a17090a17ec00b0023730efe252mr4002230pja.9.1677464036839; Sun, 26 Feb 2023 18:13:56 -0800 (PST) MIME-Version: 1.0 References: <20230209031159.2337445-1-ouyangweizhao@zeku.com> <93b94f59016145adbb1e01311a1103f8@zeku.com> <2b57491a9fab4ce9a643bd0922e03e73@zeku.com> In-Reply-To: <2b57491a9fab4ce9a643bd0922e03e73@zeku.com> From: Andrey Konovalov Date: Mon, 27 Feb 2023 03:13:45 +0100 Message-ID: Subject: Re: [PATCH v2] kasan: fix deadlock in start_report() To: =?UTF-8?B?6KKB5biFKFNodWFpIFl1YW4p?= , Catalin Marinas Cc: Dmitry Vyukov , =?UTF-8?B?5qyn6Ziz54Kc6ZKKKFdlaXpoYW8gT3V5YW5nKQ==?= , Andrey Ryabinin , Alexander Potapenko , Vincenzo Frascino , Andrew Morton , "kasan-dev@googlegroups.com" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Weizhao Ouyang , =?UTF-8?B?5Lu756uL6bmPKFBlbmcgUmVuKQ==?= , Peter Collingbourne Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: t531m9hhb8o67c41339qf1uttfagytu1 X-Rspamd-Queue-Id: 2E1D0C000D X-HE-Tag: 1677464037-51298 X-HE-Meta: U2FsdGVkX18REoUCn55ilE/vV6ZL+3EowkzwzgD9zCSO6LfdL6KmWbsJI2qriSNr4Vf6ZLsD4qxA2sCnYypuW5X6DZMntOl7YZ8NO0gFt4ADiR6Wx7+54zSMD7IMiIhVtymDKK0N5AWABQJykM66+s+wN6B6/2BjmekP+d3UO6lAiu3aNdvA/I++LTkGSApb6N0eICzM71pjOqAyHTzpydobdnvjFHRv6aRbwOi6Em97LWA3dXXQCc304YK9TIje5YRz+3WoK5eqNzcLbrrc8X2YE5vfUc5iQTGytQwHaES32pfb8/TFKKRLr2EWjNQZdO7CLXbNcgXrrfxeD6FRaPb1qAOdEk96kr8B0XIvMR30d4kMi2N9gXYlgjWmvDX7haE6BpCLYzqY2UfbeOy0qdCYGRSpt0FnQ7AEjwoJxTYvQa4IH9nXGY1INaXIrdacoFjZ1wOZbccOPDD+FLf7rXN6CuEEWulU9Blf0Th+nr7ftj27wNWPpf4JaQl3D28Jp3Sv6/cA9PAAxqk994c9Nu5cKMgrSQUDN6MRtJOQuEbpuQQ1ZRmRWIYGDZgvkpFLGOpyzyPX6SnQivaYG+YBf5BIe+I7Sv4RVPmSxrHQJ2AMBO3BKcmU2x003Aww09BnlMD+5TO2VQZ+Ie4+PazqkKmhX/kMO8Tb8Sch0slVj12xglp+yfq0i1WDQTTo7h5GczQLkbIdlm7Cr7JD5o/SXisnWAmnxKagm44gwANPt1Xqge0Zx/3wU7p7xcQownnexHwcwaI5Lf29SJWudrdzlruVnaL6JJa09COW7Woclx/AhXk5PZF5Q3uXJNeHbrMGV5iQ4PlxPYVkppjfy9X15LKNurcGzsTOo4vJ8Y+ONYVgcVT4ZVi/DGsPJLivEMx1cLYvqy/Z3I8z9ThBRULgFcgoFZuW93Kt10tN6ZjLYOQsJsS3yGewQF5TJMSq6br/zDoRi3WMvQkQ+erqiC8 FM3TJWeC 8sQzsfqZ50S1O1EMV3IYdW5qXE4PsKfOMNtFoCQO9ZOTnYdnJJPuvla96rFsfc+hpDuw4KkJHc1wUZRaGL4IVWzk0u0D6gYEXGnQkq/gKt3dkzPKSNrfM2b4k2Ml3jHdapGWP3adoEF8igmUCyd1cAA2IxVTzTJoxs/2WswT9OegaFahsrfbuDryvwDhibjm9nUqzZxqMQU3097ytWV113I3ydB02Tg6j7SYklhRKmlSF4sDXIIs0Idap3DlcgTl+ucNb9uy7JNkDTqiks4ugVe17fuHZhnqTPXQsHcQVCrXT/f3LCXMbb7pVPTcmv6CR5XSQkqbpK9IrZaN5nxrOWIiZibOht1SznltQz8qFPqQjvSyjUd2W0rxplrzsHRVWEVuCVqo642X1TuGAVrjOlx65y137kysghLKXHmzxJKvIbSZ3W0arF6nKxzXl78/k34JXKGfVB72Og4yCjSC1wzwuaoFr8LEyaCUecAdqN7uF1cmg9NsMgWVlBm+HASK8MR7gQjQf0CPKXGAOTm12Gz/hQJ85blNNGPFdSFHfLvmYp+MAfe+zSab0GJ+UglMV3FmY0HkfK5vJD0Q9Kn5eqBD8GA== 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 Wed, Feb 15, 2023 at 2:22 PM =E8=A2=81=E5=B8=85(Shuai Yuan) wrote: > > I have got valid information to clarify the problem and solutions. I made > a few changes to the code to do this. > > a) I was testing on a device that had hardware issues with MTE, > and the memory tag sometimes changed randomly. Ah, I see. Faulty hardware explains the problem. Thank you! > f) From the above log, you can see that the system tried to call kasan_re= port() twice, > because we visit tag address by kmem_cache and this tag have change.. > Normally this doesn't happen easily. So I think we can add kasan_reset= _tag() to handle > the kmem_cache address. > > For example, the following changes are used for the latest kernel vers= ion. > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > --- a/mm/kasan/report.c > +++ b/mm/kasan/report.c > @@ -412,7 +412,7 @@ static void complete_report_info(struct kasan_report_= info *info) > slab =3D kasan_addr_to_slab(addr); > if (slab) { > - info->cache =3D slab->slab_cache; > + info->cache =3D kasan_reset_tag(slab->slab_cache); This fixes the problem for accesses to slab_cache, but KASAN reporting code also accesses stack depot memory and calls other routines that might access (faulty) tagged memory. And the accessed addresses aren't exposed to KASAN code, so we can't use kasan_reset_tag for those. I wonder what would be a good solution here. I really don't want to use kasan_depth or some other global/per-cpu flag here, as it would be too good of a target for attackers wishing to bypass MTE. Perhaps, disabling MTE once reporting started would be a better option: calling the disabling routine would arguably be a harder task for an attacker than overwriting a flag. +Catalin, would it be acceptable to implement a routine that disables in-kernel MTE tag checking (until the next mte_enable_kernel_sync/async/asymm call)? In a similar way an MTE fault does this, but without the fault itself. I.e., expose the part of do_tag_recovery functionality without report_tag_fault? TL;DR on the problem: Besides relying on CPU tag checks, KASAN also does explicit tag checks to detect double-frees and similar problems, see the calls to kasan_report_invalid_free. Thus, when e.g. a double-free report is printed, MTE checking is still on. This results in a deadlock in case invalid memory is accessed during KASAN reporting. Thanks!