From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793914899; b=bqwjbgY1HkwrNCzEhQnUrFPeZT/IWyCILQIdUqZCeQtkuslFUyZNCyFqunr5XzTnAtsr XqMspzrzh5lFY1UbYEBiU90nd5uzpXmEri9ix6fx/pfrWOOlbZNaWsYXE5rVG8TxsDmtB S+C+jyyaMCElWl3nNIZNLMMO5nL9Q0R1SduyP7feIZrWyw8frOjEZv5rZgNite8Wd8XuH P6c3RXGs3Sdc3UEOV1iqXetN0TLDwzO//sd9RlLiqps6agXe0tg9Yz89//Z8ERK8KnSvZ NmpQ3zk0sa4BqoiKtEyhWT0wlTEepa2J8PBi5Cu8VXsLaHihOS2RBg7dgQHZy5gMS7A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793914899; h=Received:DKIM-Signature:Message-ID:From:Subject:Reply-To:To:Cc: In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=OC6xPJuoLtag/UNVUOAoSaQZwd0BWlf5yd9F9l2dg+8=; b=yjM/FLVkfEbOaJB/kS01H1hKB049rjjpKUaVFW/A84Nlzryu0vtRgHDw3MjHNINlZNpy 9a2B7FjZyd1wnR8D/3GRu/ixCoF5yqd3IRPLUuXjFdzmVup1mj5FPhkjWpF3ZkELHggvv ofxraMHlM0X8h/tCrARdgkJVNAGjzWE6geHIAb9eN9LUhIzu+s+lYZQKbtGWFsOM0JzBV smAekyJ2mDL1sra2X/w+EvZXA7lT+aKiZVpcDpoWn3WEVmi/HHRhhanMPS2KnNt+wkHPc bUhK++smEWeaOWBFMjtOLsh9pLnRR+VQY2ypg19g8V43LAwozSgn23DPSM1pWEboYpw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ftjSanR5; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90A05606A329; Thu, 5 Nov 2026 21:41:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ftjSanR5 Received: by smtp.kernel.org (Postfix) with ESMTPSA id B05BF1F0089F; Thu, 5 Nov 2026 21:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793914898; bh=OC6xPJuoLtag/UNVUOAoSaQZwd0BWlf5yd9F9l2dg+8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=ftjSanR5NYRVoTeBKZ9GKKb5Ejk1Wo1LW5KsXglEAcnlyjjvxN2a+oB7TS+tqIO48 mLWMUruChKgreDIeGVIBYX7RKGlsxtvnxnVOabXGjobAB/fVlZBcpRSb4QcmM+aPey H1GN8tWl7V0jJslBLXgjRHT2fPyQBR4w0/b8W6NY2gw07MVWVDA9NQN/Y11ulVuQIA 85VS68u9z1a4tjmBgnUKmKpo/fWULan3ie+4z30hlSVqrPQol/nhiJzLckViEBmmge zkrugiLnzvT9AifyLkUuMzOvKx+kKGulAQEqHn+yOT6n1ONFUVd0hOc+ZZVtqSd1Kf 1pcTL4VXazLdw== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH 02/13] mm/filemap: convert fault and readahead logic to use vma_flags_t Reply-To: sashiko-reviews@lists.linux.dev To: =?utf-8?b?TG9yZW56byBTdG9ha2VzIChBUk0p?= , "Andrew Morton" , "David Hildenbrand" , "Jason Gunthorpe" , "John Hubbard" , "Peter Xu" , =?utf-8?b?TWF0dGhldyBXaWxjb3ggKE9yYWNsZSk=?= , "Jan Kara" , "Rik van Riel" , "Liam R. Howlett" , "Vlastimil Babka" , "Harry Yoo" , "Jann Horn" , "Lance Yang" , "Zi Yan" , "Matthew Brost" , "Joshua Hahn" , "Byungchul Park" , "Gregory Price" , "Ying Huang" , "Alistair Popple" , "Baolin Wang" , "Nico Pache" , "Ryan Roberts" , "Dev Jain" , "Barry Song" , "Usama Arif" , "Kiryl Shutsemau" , "Xu Xin" , "Chengming Zhou" , "Madhavan Srinivasan" , "Nicholas Piggin" , "Michael Ellerman" , =?utf-8?b?Q2hyaXN0b3BoZSBMZXJveSAoQ1Mg?= =?utf-8?b?R1JPVVAp?= , =?utf-8?b?Uml0ZXNoIEhhcmph?= =?utf-8?b?bmkgKElCTSk=?= , "Shrikanth Hegde" , "Pedro Falcato" , "Kairui Song" , "Qi Zheng" , "Shakeel Butt" , "Axel Rasmussen" , "Yuanchu Xie" , "Wei Xu" , "Baoquan He" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , "Leon Romanovsky" , "SJ Park" , "Rakie Kim" , "David Rientjes" , "Alexander Viro" , "Christian Brauner" , "Peter Zijlstra" , "Ingo Molnar" , "Arnaldo Carvalho de Melo" , "Namhyung Kim" , "Mark Rutland" , "Alexander Shishkin" , "Jiri Olsa" , "Ian Rogers" , "Adrian Hunter" , "James Clark" , "Masami Hiramatsu" , "Oleg Nesterov" , "John Johansen" , "Georgia Garcia" , "Paul Moore" , "James Morris" , "Serge E. Hallyn" , "Mimi Zohar" , "Roberto Sassu" , "Dmitry Kasatkin" , "Eric Snowberg" , "Fan Wu" , "Stephen Smalley" , =?utf-8?b?T25kcmVqIE1vc27DocSNZWs=?= Cc: linux-mm@kvack.org, kvm@vger.kernel.org, damon@lists.linux.dev, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org In-Reply-To: <20261105-late-2026-vma-flags-v1-2-0d3cd15ab75f@kernel.org> References: <20261105-late-2026-vma-flags-v1-0-0d3cd15ab75f@kernel.org> <20261105-late-2026-vma-flags-v1-2-0d3cd15ab75f@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 05 Nov 2026 21:41:34 +0000 X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [High] mm/filemap: use-after-free on vma in do_sync_mmap_readahead() - [Low] mm/filemap: inner vma declaration shadows outer vma in do_sync_mmap= _readahead() -- commit f5f0f8e634a6a2e2b76ad818de67e83f30cb7dea Author: Lorenzo Stoakes (ARM) mm/filemap: convert fault and readahead logic to use vma_flags_t This commit replaces direct checks of vm_flags_t values with vma_flags_t helpers in the filemap fault and mmap readahead paths. > diff --git a/mm/filemap.c b/mm/filemap.c > index b74bc1e5015c6..d8b538bd14043 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -3351,13 +3351,14 @@ static struct file *do_sync_mmap_readahead(struct= vm_fault *vmf) > struct address_space *mapping =3D file->f_mapping; > DEFINE_READAHEAD(ractl, file, ra, mapping, vmf->pgoff); > struct file *fpin =3D NULL; > - vm_flags_t vm_flags =3D vmf->vma->vm_flags; > + struct vm_area_struct *vma =3D vmf->vma; > bool force_thp_readahead =3D false; > unsigned int thp_order =3D 0; > unsigned short mmap_miss; [ ... ] > @@ -3414,7 +3416,7 @@ static struct file *do_sync_mmap_readahead(struct v= m_fault *vmf) > * Fetch two folios so we get the chance to actually > * readahead, unless we've been told not to. > */ > - if (!(vm_flags & VM_RAND_READ)) > + if (!vma_test(vma, VMA_RAND_READ_BIT)) > ra->size *=3D 2; > ra->async_size =3D folio_nr_pages; > ra->order =3D thp_order; [Severity: High] Can this trigger a use-after-free on vma? Previously, do_sync_mmap_readahead() cached vmf->vma->vm_flags by value in a local variable at entry while the fault lock was held, as introduced by commit dcfa24ba6899 ("filemap: Cache the value of vm_flags"). In the force_thp_readahead block, maybe_unlock_mmap_for_io() is called befo= re this check: if (force_thp_readahead) { unsigned long folio_nr_pages =3D 1UL << thp_order; fpin =3D maybe_unlock_mmap_for_io(vmf, fpin); ractl._index &=3D ~(folio_nr_pages - 1); ra->size =3D folio_nr_pages; /* * Fetch two folios so we get the chance to actually * readahead, unless we've been told not to. */ if (!vma_test(vma, VMA_RAND_READ_BIT)) ra->size *=3D 2; Since maybe_unlock_mmap_for_io() only pins vmf->vma->vm_file and calls release_fault_lock(vmf) to drop mmap_lock or the per-VMA lock, isn't vma unprotected against concurrent modification or freeing when vma_test(vma, VMA_RAND_READ_BIT) dereferences vma->flags? > @@ -3422,7 +3424,7 @@ static struct file *do_sync_mmap_readahead(struct v= m_fault *vmf) > return fpin; > } > =20 > - if (vm_flags & VM_EXEC) { > + if (vma_test(vma, VMA_EXEC_BIT)) { > /* > * Allow arch to request a preferred minimum folio order for > * executable memory. This can often be beneficial to [Severity: Low] Does the newly added outer vma declaration in do_sync_mmap_readahead() cause the existing inner declaration in this VMA_EXEC_BIT block to shadow it? if (vma_test(vma, VMA_EXEC_BIT)) { ... struct vm_area_struct *vma =3D vmf->vma; const unsigned long start =3D vma_start_pgoff(vma); const unsigned long end =3D vma_end_pgoff(vma); Should the inner vma variable be removed now that vma is declared at functi= on scope? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261105-late-2026-= vma-flags-v1-0-0d3cd15ab75f@kernel.org?part=3D2