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 C96FEC00A94 for ; Mon, 15 Apr 2024 23:03:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C0846B0087; Mon, 15 Apr 2024 19:03:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 470176B0088; Mon, 15 Apr 2024 19:03:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 336F96B0089; Mon, 15 Apr 2024 19:03:03 -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 162876B0087 for ; Mon, 15 Apr 2024 19:03:03 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 86613A1CD4 for ; Mon, 15 Apr 2024 23:03:02 +0000 (UTC) X-FDA: 82013293404.15.3232F4A Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) by imf15.hostedemail.com (Postfix) with ESMTP id C5C12A0007 for ; Mon, 15 Apr 2024 23:03:00 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KfJr6KWY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713222180; 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=zixM8fcSFTGU7EoKEyJyngzis3PHUKVx8GoIuPBbUXk=; b=K5D/CAnpip3lBhQQFE4RNf3qsyujVELOkOpAZS2IQr4udfIqxOmoOeEzDeBLwFMjdASCRz J6aaBhz2a2AWpN2MlVIqHCAYJc5yClugQP/QzBLAFIKrsjnoeyPJE7XvaRzmHdK1SqgZhj QqplBTqRAYN858S6CN+bBOhs/sphEdQ= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KfJr6KWY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713222180; a=rsa-sha256; cv=none; b=HkmJmoWJEhm3uY/3sfg2WHOz1XXNzscLTkU/dRAOPZSUQPqPCJUU6v5udVE2BKJhGMsaTo ar5TqujchcUQFaizjGzPV2FwIawYHC+MOi4fkkVsR8RoVc+oKJA2picqFCmdDOocvgm/4V 45w/k92FFuBswifYq4jibHc4e803Wqc= Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-6184acc1ef3so39029177b3.0 for ; Mon, 15 Apr 2024 16:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713222180; x=1713826980; 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=zixM8fcSFTGU7EoKEyJyngzis3PHUKVx8GoIuPBbUXk=; b=KfJr6KWYG2Knjq2zjquEcozBILw/69SB5Epy1qqC9p0xRLQevDR1tqtb1I833Dj1Ys YGB2JwlmtPRMBEzilUSn5MGN3Bterlz/w6Lt0NYZpFA3kMs6fd6OwLkR4MUqu/nybEMi Gsoaejbhu6/eCtsLlnCM+9TblkD5HHw9LOfSou40n/4U4O8Q4CusDNA9cfXn5tB2RzFg w2VH59PjJ2gkcjtLyt69B6fohLfLj63xgPrN+ykJ8KQnqWyp1IGw2fCEkSQvwRwKldoj ImJYPC7dDEsT2THc79W37wt+PJD0dSF5+7DJLJoSDS9xb5rLwWmLsLGHXiP4moXzpobT 3Flg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713222180; x=1713826980; 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=zixM8fcSFTGU7EoKEyJyngzis3PHUKVx8GoIuPBbUXk=; b=knZYQ9ayQQDaUwh/HOAvT3rndx1jXx2fBJuXrxlhY7U4YUZhk3DSbWRZ0bu+xdxDLF t2XFYVRditq16hwQlGRCGrRT6fbuXiSIVW9ClE43k2dxgJRYYhi6Q9yt/yjiE4/joteK jgE7C6yTy4i9HIoM1lHEUySFzX4gaUKBfeXjN3ovCFDpZL66dOtxVVjwECYL6/OcDmS8 14b3R2DgXniJgrOiOIKVhhd/5LwNekDmz1M4qz1zbCmabm7gXFUPx6pHQMZf3NLfWJZZ nu3m/jdAjDGNqzZsmEG+JMeMWurAPZhD01yVX/ypZr+nlSCMhl28N1nVEB4FDe887IwZ uGdw== X-Forwarded-Encrypted: i=1; AJvYcCXCm2//sIgVT0/85B5TscxjytTv9p+eRN7I9qpZNwdTANxs6YduR3fsjN8ycXUrd6oVN4ircMS6IJgMEE0NpfN1VDc= X-Gm-Message-State: AOJu0YyxFB5/oBETNoEXnbMq9muaVtOd25CJj/lVDCEogiMdRZ0pJHzj 2XX2SlxXTE34RUmLbfnaAtGcBG+MEVWnfcoqlIMHPLHFozajESX8BJwIiwpA/sKiCqxdyqTYLwD XXGcP3KCR4D/7kO+R6fxmL0cbdxk= X-Google-Smtp-Source: AGHT+IGXsz28y5CQ10Oefmh9Jx2hMsRnfKUS2iaknbNbz0ZrfM5C4L7WBIj/DzJrUu/xhPwAlAfj+hnsRuIZ3O9CgU4= X-Received: by 2002:a25:ac24:0:b0:dc7:6f13:61e2 with SMTP id w36-20020a25ac24000000b00dc76f1361e2mr11247143ybi.58.1713222179867; Mon, 15 Apr 2024 16:02:59 -0700 (PDT) MIME-Version: 1.0 References: <000000000000daf1e10615e64dcb@google.com> <000000000000ae5d410615fea3bf@google.com> In-Reply-To: From: Vishal Moola Date: Mon, 15 Apr 2024 16:02:48 -0700 Message-ID: Subject: Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common To: Matthew Wilcox Cc: syzbot , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, muchun.song@linux.dev, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C5C12A0007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: r6hhaak1z9wtaxiua79re6y416j7t6as X-HE-Tag: 1713222180-863712 X-HE-Meta: U2FsdGVkX19QlpxmTbmCnfr+c5zAqlF6C6tSQ8j3B+tQyPf707IS6oKYb/sOFGO6YOW8/1d5PUVmDRRDAyqKKbr7YZ2x9xzBzyRXLxkdQTEIEyMQRSksDTBPACouBRbybkpd9/MyPIuIWuDVftchQ2p6YCj7pAw6apxFqnuGiB4ODmT62Ni18A6n12n1DOXzro5WwNSXXjiX4VSSVnx4/CaqknIZX56UCp7q1wZgHN/XOa8N88dPs6za4SW6P+VxDjPVqHFphDeZMpl4jjOlY9FW8TmoHsRo8B6p/Ix0FLjMu0TR8+W+Asi4wkZ/i9V3uLekeY6I8ubON4L9Qiu/cD6Nv2+gF3Eu+ceWLmnjE/nHfVSI8hp78GBGysmG7s/C/4uyhe/6Hakn+mHx/yrlyco4Ns3KwJbiVW+tLI2f1zY3ZaaXNPEJR4NHEF4UdsxQgbxQpDlLnjjKsVMS1X90pIc0X4LLtR5AtQlZCboxgcA50g9O7rdMDwSq5aBpte+vGZnmL+8R/9ZHXGKf32EFKLgponk5jR/ZpX+pwcdf2da86hAPfLTNl8LVdNuAnuO1YGH0rVDJ7CvF+rd0Jwxk9N/RitronnaPiLZpfKNTChslq+Lp1hVt2eA0PzgC65uALFPmzM4cXwpdbjWEctC4GGo5zDJZGCDPrYmaseNaX7qBKY1KVbXMq0S9dhSSEMO15FT12EIckGalaJ8j86ohO7IPvLcn0hzeEe4qjme0F5D0NIRc/03k1m2Qt6EReAf3yJDvEyuaoyRloNuGRfWb/+tYDeoIBDwlEL+TwUt7IY29T/1q3Nat9HsfOcgTRP+syC+m1lDlowNHmtSeYsNW88HXENzKk5P2p4mdzJuw+enRmvkFfJDJxTDro+OFOAmNfKdI4QIRSgK37C5ZMLEbVm4CcZwhj97ISyOuihSie9laigbRhPM31hgbpN43st1And6S9EwiTy+Vn89jr8T c7pIbf5c x+g9eq0moKZtdA4Xsaq7YU6cIPlUtnjSP5jNHbDoZTxkQP/rWoLx7r/K5KTx90+Gi+W9NpMjm3O3MmcImk8EBzo0cVdxQwq3UTt74M76nilejoAEBRa1/e6p7EFQLQq53bF0uFNh0JV6W1x0z1/myVV4D1R0nVH/Pwtg16hqF5+QTFtxntme34KFUfeZIkYGtXRoPOkjTGf9XT9U4OHatSjayKOJ4jeEhVU3oGkT3EebK920VLplOU96b0s3J/3LBHEZVj4voIVFwl8rzTrTR0iQN1XvEJpwWw+g1Ycbicb71w9VGVo3fJZD8Wsz5Y3Vz6HSiXKbODyk7ZE+qYORxvs0aTfpmijYbY4EQqnT4tgLSgiS1qxfqqZ8hxgy6+x1v3oTM7KyQ4Fc+np1c3f22eOSRlYw/axQ9szDPQbtbWjL9sLufriQTt70k39IHllh68W07tgVD8Iz4X0mTWWqChqjVlWA3/uiXidlJM5ckKBUxH3j4uI0FVf2KIZ0CTJxw/LmYOjTaUr324Ga7v7xpvGLKpq93LVWTrJzgsjt3HsDg+CVZu8jI9T3sX/4zJDFfWjuPibVMCoFAGAi+fev/ZSTbjg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.028626, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Apr 15, 2024 at 3:15=E2=80=AFPM Matthew Wilcox wrote: > > On Mon, Apr 15, 2024 at 03:05:44PM -0700, Vishal Moola wrote: > > Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of > > anon_vma_prepare()") may bailout after allocating a folio if we do not > > hold the mmap lock. When this occurs, vmf_anon_prepare() will release t= he > > vma lock. Hugetlb then attempts to call restore_reserve_on_error(), > > which depends on the vma lock being held. > > > > We can move vmf_anon_prepare() prior to the folio allocation in order t= o > > avoid calling restore_reserve_on_error() without the vma lock. > > But now you're calling vmf_anon_prepare() in the wrong place -- before > we've determined that we need an anon folio. So we'll create an > anon_vma even when we don't need one for this vma. That's true. Though that can be addressed through something like: if (!(vma->vm_flags & VM_MAYSHARE)) { ret =3D vmf_anon_prepare(vmf); if (unlikely(ret)) goto out; } > This is definitely a pre-existing bug which you've exposed by making it > happen more easily. Needs a different fix though. I interpreted the bug report to showcase how restore_reserve_on_error() depends on the vma lock being held - and vmf_anon_prepare() drops that lock by the time we get to restore_reserve_on_error(). In this case, this would address it without reworking restore_reserve_on_error(). There very well could be something completely different going on, however I have no ideas as to what that may be.