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 307E7C77B7F for ; Mon, 23 Jun 2025 12:51:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3BE78D0005; Mon, 23 Jun 2025 08:51:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BECD46B00A3; Mon, 23 Jun 2025 08:51:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B02A38D0005; Mon, 23 Jun 2025 08:51:43 -0400 (EDT) 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 9F2546B009B for ; Mon, 23 Jun 2025 08:51:43 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3B689C0311 for ; Mon, 23 Jun 2025 12:51:43 +0000 (UTC) X-FDA: 83586652086.06.F1E093C Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 57463140008 for ; Mon, 23 Jun 2025 12:51:41 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750683101; 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; bh=7KTzKJJv/eR7nZSw5vO3bIegvvHZ++8VXc8KctU3W9w=; b=vTwbMEws0nZ3slBvbec8dIM3QgkWW8uowMxJf+j7Z+c5l2J5Hq1pJ2oH2HafNxVqk5I5jt HTpvGq8zsj/x7EGo/G5efdXtRiycr6duWHIw6JZx0ACTGQXufLvgEVFueU+irNr+MLiQ/G PwQxyEagqmyoopr9w5KpjFJiBnSyYSk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750683101; a=rsa-sha256; cv=none; b=js0jgElE05pqrkDbU7jnj1Qphs01EUnGMKlLdlqmoKtAVDq2U1sAVapuDnEfb7L+cJOR7c WCMPnph+Nzkn11hw1+5y2+jo4YXa4VcwJFzgH+Yvc5TxLPssb+0CKoBwEByF+GZzhvK568 8IpwNWdEZiydDfjvnng72m4XU9q7FJU= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2ADAF113E; Mon, 23 Jun 2025 05:51:22 -0700 (PDT) Received: from [10.1.29.169] (XHFQ2J9959.cambridge.arm.com [10.1.29.169]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 231723F58B; Mon, 23 Jun 2025 05:51:39 -0700 (PDT) Message-ID: <40f3d567-e3f1-4beb-b05f-db76b144fd69@arm.com> Date: Mon, 23 Jun 2025 13:51:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in do_sync_mmap_readahead Content-Language: en-GB To: Hillf Danton , Jan Kara Cc: david@redhat.com, jhubbard@nvidia.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com References: <6852b77e.a70a0220.79d0a.0214.GAE@google.com> <20250621012029.1386-1-hdanton@sina.com> From: Ryan Roberts In-Reply-To: <20250621012029.1386-1-hdanton@sina.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 57463140008 X-Stat-Signature: 9t8wcuff8pifr9q5gs74dk5h335cb137 X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1750683101-920330 X-HE-Meta: U2FsdGVkX1+mQhHbyZxzn4eUGZdytdi+TVFg3J7quwIbEZOZ7fa4fIhk0R5qY9UBpKE1RfiLOKP2km8HrSrB7zrb0sEUoBl1nff/oqtPxiYdMqtZ6wB2tH9NXL++mFckJc2azwTNXKhWrwjqNEEg1FaYTsRRo1Zq8dMblS2qHIlBYtWz/bZlMpsHpfb5zw5hpUJvuGMfVF9Nfh1bfbTGANN7i24XzLGyEQRzp8mAwNCyd3nCL57B6AIucsEcsReiiU+Q9/U6szcCVB3GHsjLlPA4BCy3DDRiNHc8styLtsetlIt+aclC7vkBcmfHE/T2tV6OVueBLWUnyoSyIlCe7G0wzX5ILyLgE8K2lhLCW0UVCa1uEmASG9N6FPzAQXMGfH9ex0Q2EJ0AAM9dPiIFtP/oAra3KRN7+7eyDwmT4ssIgJbteFwvJ9x9P3JO9VIK646TIKE9eehQK3D/dB6rqN7RKtbPJjl7SyQTl8X0HS6c8pWODim3cOWa3sB08+BFL3xKNjWgLbRpeJ8OifRy0BWnvHVaCAEUUyrtOBdAssq6hR74UO8sq9R7VLTE3ROosCGakrHf4CZSGd6Yng8bGF4/04wfcYbS2Pkrst0zTa8/vX4wKdR1Ov1FsAO88wj9IiAerBQEVYkYJ4P7chWvzhVX/w65jjiRQ5JXisTtxbT+0rfEqR6rQSKdYPe4UEnN4ubbgBpx43ZrcJdcby0DSKLMruoAEG6OtIzJthH3C3fCsXaSFjdeVvgbXeY4GSVN1sobFsW1Df0cDe/bCSpryRmoIbbrAxnEKRrvom1VWz0i48edy0xTt2EPSbuzCz5THZc0SMQOV2H9WAectFR3sTz7jWlzbQCeXJruqXiB+Ctgn+Bt0vlfWwTRCuK8UN03m1qelsP75jrBSTvbMfwzfdHSTO3MBDSlswcOCG5MYjrJUoVUCAdWpn07BWB0Ho/WLvYulRmPd6fP3Np0Y5M BMPd83fQ IR+9D5Bs/qtZ8o4H/nJwFzvVrm6rnsszMzvzaOFsk3AO9T/Z0U9x1jGg09QiIrYWmNvMAxuRC9ADGXjAYoUlhvgh2N8lh5ohnNgXVH268ZwxldD76zPzQF1aX3jVjU7v61v4Kug/pPMd/hrmUh0f0S1fBrBXxsCykpn+jqkSokFjVPZPCLgEUdQp3l+pnSvxeFXaSFgTXYF5cRcWjDKaVNl9RxUthhKa5jVx8PKjDk/u1K8zimW9nDHNGECZQuqZCEGgpnuXdrY4d8i/z9FrV5DgVKb1qiMssH8To7qEBZkgXvNWGwvmu23B5LmK7D4LotEZSZBUwOaYnk3m89UI6HOy2ZIHOk/tZbkikjencWop4YrgvsfBTeeCUViDbse8ogKXUPxu4baXgAJlh+9NMuHJ38osaHiD0sg9HdaK/jCUTQuPn0x2wuaYqhm3OgXtdaKneiD9Snjx1rAa4L9dogfXNUA820yPTFmsAQ4KWCvP3gr7tB6p3+38E9a3aBh0S5O0mrAlAYuvjDNjNoQNyqWpXTFeDrAxFcR+U941JW4H1zr6ue1fQavNnjmE2iuV3shf6pn4o9m/IHRL3rrZy3HsdsGCO0QzZejIExolU+2yE4XxIRKNWBxAuhihTBU2mvaTBvFWwe2XPe1jmajkxAl4tM3oCY0o3KwIfWkbK56+MrEk3uw/88EtKr/V+Uuqz7JwNhB3KNA5A6GSDCjRy7hehJxhEjc8K86W3JJeePWzvXvqsAqtxUUp/lxXc1WUzgmxYL4YECWXvFaZhp7odMt1ojg== 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: List-Subscribe: List-Unsubscribe: On 21/06/2025 02:20, Hillf Danton wrote: > On Thu, 19 Jun 2025 11:52:43 +0200 Jan Kara wrote >> On Wed 18-06-25 05:56:30, syzbot wrote: >>> Hello, >>> >>> syzbot found the following issue on: >>> >>> HEAD commit: bc6e0ba6c9ba Add linux-next specific files for 20250613 >>> git tree: linux-next >>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=108c710c580000 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=2f7a2e4d17ed458f >>> dashboard link: https://syzkaller.appspot.com/bug?extid=8e4be574cb8c40140a2a >>> compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6 >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=148c710c580000 >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=179025d4580000 >>> >>> Downloadable assets: >>> disk image: https://storage.googleapis.com/syzbot-assets/2430bb0465cc/disk-bc6e0ba6.raw.xz >>> vmlinux: https://storage.googleapis.com/syzbot-assets/436a39deef0a/vmlinux-bc6e0ba6.xz >>> kernel image: https://storage.googleapis.com/syzbot-assets/e314ca5b1eb3/bzImage-bc6e0ba6.xz >>> >>> The issue was bisected to: >>> >>> commit 3b61a3f08949297815b2c77ae2696f54cd339419 >>> Author: Ryan Roberts >>> Date: Mon Jun 9 09:27:27 2025 +0000 >>> >>> mm/filemap: allow arch to request folio size for exec memory >> >> Indeed. The crash is in: >> >> fpin = maybe_unlock_mmap_for_io(vmf, fpin); >> if (vm_flags & VM_EXEC) { >> /* >> * Allow arch to request a preferred minimum folio order for >> * executable memory. This can often be beneficial to >> * performance if (e.g.) arm64 can contpte-map the folio. >> * Executable memory rarely benefits from readahead, due to its >> * random access nature, so set async_size to 0. >> * >> * Limit to the boundaries of the VMA to avoid reading in any >> * pad that might exist between sections, which would be a waste >> * of memory. >> */ >> struct vm_area_struct *vma = vmf->vma; >> unsigned long start = vma->vm_pgoff; >> ^^^^ here >> which is not surprising because we've unlocked mmap_sem (or vma lock) just >> above this if and thus vma could have been released before we got here. The >> easiest fix is to move maybe_unlock_mmap_for_io() below this if. There's >> nothing in there that would be problematic with the locks still held. >> > In the fault path (arch/arm64/mm/fault.c), vma is locked for read. > > do_page_fault() > vma = lock_vma_under_rcu(mm, addr) > handle_mm_fault() > > While in the mmap path [1], mm is locked for write but vma is removed without > locking vma for write. > > vm_mmap_pgoff() > mmap_write_lock_killable(mm) > do_mmap() > mmap_regionC() > __mmap_region() > __mmap_complete() > vms_complete_munmap_vmas() > remove_vma() > > Thus the correct fix looks like locking vma in both mmap and gup pathes [2]. Hi Hillf, do_sync_mmap_readahead() was already accessing the vma prior to my change, but it was doing so before calling maybe_unlock_mmap_for_io(). I think that you are saying that there exists a separate race whereby it's possible for a vma to be removed even when the vma is locked? In which case, I think we need both fixes? FWIW, Andrew has already updated mm-unstable to include the fix to ensure we don't access the vma after calling maybe_unlock_mmap_for_io(). Thanks, Ryan > > [1] https://lore.kernel.org/lkml/685535d2.a00a0220.137b3.0045.GAE@google.com/ > [2] https://lore.kernel.org/lkml/68555d6e.a00a0220.137b3.004c.GAE@google.com/