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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DD3651090221 for ; Thu, 19 Mar 2026 12:52:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A4E86B04A5; Thu, 19 Mar 2026 08:52:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 06D5F6B04A6; Thu, 19 Mar 2026 08:52:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAD896B04A7; Thu, 19 Mar 2026 08:52:37 -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 D92206B04A5 for ; Thu, 19 Mar 2026 08:52:37 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6402C13B189 for ; Thu, 19 Mar 2026 12:52:37 +0000 (UTC) X-FDA: 84562801554.08.CFC2A59 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf15.hostedemail.com (Postfix) with ESMTP id 086FFA000E for ; Thu, 19 Mar 2026 12:52:35 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Udm/5szm"; spf=pass (imf15.hostedemail.com: domain of ljs@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=ljs@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1773924756; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wOH+Jpbsz+GbffyZaW9wu+S1aB13FCuri293r4+v3Rc=; b=j2JCS1sQXWY/TUdztjnUiCreBJmhPztHBKUBYs55pJGKhEH7kThAwWfwVR5djY9InqbNMO 4IzN//RNeiVLy0n55nAt+xDZAZerBAuD67WUW/zID3Zw117I96C6nVuNtwT4i3A+yU13p0 1Av9Te7j0k4WlE+SrGE4d8AushwdMUk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1773924756; a=rsa-sha256; cv=none; b=h/R4OmyYMwUKaKPwHH5qddgFyl5WbXmAbCo7HuBHQlqY5DhpD/7rBHWLLomVpNnZfM0bFS Bg/1AJ9YVNudueAIWvnQN55VRpG/5+znINQNr1amrJdkPV4g7YEua2VxKRaOztbsq5rf4n jBIuGfWsU126UrSFzkohVrQodEjPawE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Udm/5szm"; spf=pass (imf15.hostedemail.com: domain of ljs@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=ljs@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 4926C600C4; Thu, 19 Mar 2026 12:52:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9282C19424; Thu, 19 Mar 2026 12:52:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773924755; bh=jA7diFAaatzjClu0BNNjaXH84miUw/aL+tXzTcfiSyY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Udm/5szmcmrn1FQPUv6e/j0SN6gP++q+sDVLk95f5h2PMysLxA/Z+vmQxnocUccUn NuBv89GwjGw+atxJn1J0so9qkU5Fz40p+PTENxR41hcO8d78y7WoL7d68u7RJwiVoU 24b8F9r9Rglgs2jG81B2Ku5fqywDVKhnmPJe34SHQaQbe0jVM5wnV7X8Yl87k20mNN uLVYl3OTVyKbPcX2UWMxSpOwWjfeL17ZUhqEmwTrU9V9I6dAEZqrK0WhNYjr1Zk1rv FL2a3cllmUIkPZSTj7CNTbJNtleLxEuRoC6olnUM1WEiLl3YJslQyYkYq6xD3FW/z0 rvKJyE92if+Dg== Date: Thu, 19 Mar 2026 12:52:22 +0000 From: "Lorenzo Stoakes (Oracle)" To: Joshua Hahn Cc: Andrew Morton , Clemens Ladisch , Arnd Bergmann , Greg Kroah-Hartman , "K . Y . Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Alexander Shishkin , Maxime Coquelin , Alexandre Torgue , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Bodo Stroesser , "Martin K . Petersen" , David Howells , Marc Dionne , Alexander Viro , Christian Brauner , Jan Kara , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-mtd@lists.infradead.org, linux-staging@lists.linux.dev, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Ryan Roberts Subject: Re: [PATCH v2 12/16] mm: allow handling of stacked mmap_prepare hooks in more drivers Message-ID: References: <72750af6906fd96fb6f18e83ac3e694cf357a2c1.1773695307.git.ljs@kernel.org> <20260318210845.2591228-1-joshua.hahnjy@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260318210845.2591228-1-joshua.hahnjy@gmail.com> X-Stat-Signature: wtorcj63gwur3ik145u1skxncatmmj18 X-Rspam-User: X-Rspamd-Queue-Id: 086FFA000E X-Rspamd-Server: rspam12 X-HE-Tag: 1773924755-302394 X-HE-Meta: U2FsdGVkX182P1MpuTZVpCRcxD1Solmsj4XWWmc0NXXRRfoNkgK+qwU11iWYKU/OeOEsu92Mr9ndLZ8SEcs488d3mGuq5Oj51gXTGpKq1yK+PQ2IDnbQ9eW1qKA4c3PIrmGBv9QqLyaAbmz0ri6xN7O37LNFSX1lCUoOw3EixiTcCEu6Cu1lVg6X2AD+XgfAdeQoeaMo2CV3+SNbGxfwPbM90ThjMGVrDSsATnknFL30kjXDmEgQGb1TL2HgFnExxLHNayl6pvZFWgpGlNkCAx54MHPfWAgXR1iu+I9Fk4g+XtrY6di/+FBL5Qg1hyPG9lVgPGnR93NPgI2ctef48vAn+TNWIe7J80tB9p1DWmr9vT8NmLhgNr4JSqYZDh3QfK7C0rlmE2OIezvsxG7cx39TtINS0i/iQ4Mng23MoI/z/J+/pFi04cDSY1Ll2+HOrq8jmYFwTDtk/d+kSfWXBtOUnPrSLbCOiAdbt60kRoYSA2mG75jHaRCjjGwJgatQhVEmsVcWMQ0r+4yFsSisr+WADaFf2kAu0/MytGJe9yZblGNwNtu9ijjCJMcxgxUhZwEswhBCi364IKviID/GUT138NLf3PV4a7+5dmXcbKgYlx3wmBJmh0hkTd/LX/AK7JQ0s5ZuS2qr/6Gu+PkLotJzds2nDNBW9t/9YLsXfSngYg9SYS9Voor9an5pgNocUGkGNB3nq4sGvK7JGX39G0Nvws8eUnLmCAYyRURvZ0rfLaKE/OOaaXS0oxiKyter/3jLSkcOhGGJu8016RFBe++f8EE6XtOyw007PMBOqSDzNZvQfFQ7RyvQeK2ogcAscLw6FuKOvGGKpXyLs5mbbD2Ar2k3ag4sbMuU8GSCaAzzhXXK2INOmmbIk1E6Pe5BpCn/ukpdNqR5DYgRJlk5OngN55Wh+PRFKdfD1Kzc5dkynDm6OMFUsK4KF4kFVH97dTsrAudtquDibIhRCKn PKuu1joG DyLHsvYT355t1qNfVHs2oTA4GoJD9k7LR4fQi Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Mar 18, 2026 at 02:08:45PM -0700, Joshua Hahn wrote: > On Mon, 16 Mar 2026 21:12:08 +0000 "Lorenzo Stoakes (Oracle)" wrote: > > > While the conversion of mmap hooks to mmap_prepare is underway, we wil > > encounter situations where mmap hooks need to invoke nested mmap_prepare > > hooks. > > > > The nesting of mmap hooks is termed 'stacking'. In order to flexibly > > facilitate the conversion of custom mmap hooks in drivers which stack, we > > must split up the existing compat_vma_mapped() function into two separate > > functions: > > > > * compat_set_desc_from_vma() - This allows the setting of a vm_area_desc > > object's fields to the relevant fields of a VMA. > > Hello Lorenzo, I hope you are doing well! > > Thank you for this patch. I was developing on top of mm-new today and had > an error that I think was caused by this patch. I want to preface this by > saying that I am not at all familiar with this area of the code, so please > do forgive me if I've misinterpreted the crash and mistakenly pointed > at this commit : -) > > Here is the crash: > > [ 1.083795] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) > [ 1.083883] BUG: unable to handle page fault for address: ffa00000048efbb8 > [ 1.083957] #PF: supervisor instruction fetch in kernel mode > [ 1.084030] #PF: error_code(0x0011) - permissions violation > [ 1.084086] PGD 100000067 P4D 10035f067 PUD 100364067 PMD 441ed9067 PTE 80000004466a3163 > [ 1.084162] Oops: Oops: 0011 [#1] SMP > [ 1.084218] CPU: 0 UID: 0 PID: 305 Comm: mkdir Tainted: G W E 7.0.0-rc4-virtme-00442-ge53de5a0302f-dirty #85 PREEMPTLAZY > > As you can see, it's on a QEMU instance. I don't think this makes a difference > in the crash, though. > > [ 1.084321] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE > [ 1.084369] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-5.el9 11/05/2023 > [ 1.084450] RIP: 0010:0xffa00000048efbb8 > [ 1.084489] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <40> 12 0e 00 01 00 11 ff d0 fa 8e 04 00 00 a0 ff 80 33 51 02 01 00 > [ 1.084642] RSP: 0018:ffa00000048ef998 EFLAGS: 00010286 > [ 1.084692] RAX: ffa00000048efbb8 RBX: ff11000102512cc0 RCX: 000000000000000d > [ 1.084766] RDX: ffffffffa06247d0 RSI: ffa00000048efa18 RDI: ff11000102512cc0 > [ 1.084826] RBP: ffa00000048ef9c8 R08: 0000000000000000 R09: 0000000000000007 > [ 1.084889] R10: ff110001047d1f08 R11: 00007effdc3d0fff R12: ff110001047d3b00 > [ 1.084954] R13: ff11000446cae600 R14: ff110001024efe00 R15: ff11000102510a80 > [ 1.085021] FS: 0000000000000000(0000) GS:ff110004aae72000(0000) knlGS:0000000000000000 > [ 1.085083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 1.085136] CR2: ffa00000048efbb8 CR3: 0000000102667001 CR4: 0000000000771ef0 > [ 1.085201] PKRU: 55555554 > [ 1.085228] Call Trace: > [ 1.085248] > [ 1.085274] ? __compat_vma_mmap+0x8e/0x130 > [ 1.085318] ? compat_vma_mmap+0x76/0x80 > [ 1.085354] ? mas_alloc_nodes+0xb2/0x110 > [ 1.085390] ? backing_file_mmap+0xc3/0xf0 > [ 1.085426] ? ovl_mmap+0x41/0x50 > [ 1.085463] ? ovl_mmap+0x50/0x50 > [ 1.085499] ? __mmap_region+0x7e8/0x1100 > [ 1.085539] ? do_mmap+0x49f/0x5e0 > [ 1.085573] ? vm_mmap_pgoff+0xef/0x1e0 > [ 1.085609] ? ksys_mmap_pgoff+0x15c/0x1f0 > [ 1.085647] ? do_syscall_64+0xab/0x980 > [ 1.085684] ? entry_SYSCALL_64_after_hwframe+0x4b/0x53 > [ 1.085730] > [ 1.085770] Modules linked in: virtio_mmio(E) 9pnet_virtio(E) 9p(E) 9pnet(E) netfs(E) > [ 1.085838] CR2: ffa00000048efbb8 > [ 1.085874] ---[ end trace 0000000000000000 ]--- > [ 1.085875] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) > [ 1.085918] RIP: 0010:0xffa00000048efbb8 > [ 1.085921] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <40> 12 0e 00 01 00 11 ff d0 fa 8e 04 00 00 a0 ff 80 33 51 02 01 00 > [ 1.085988] BUG: unable to handle page fault for address: ffa00000048f7bb8 > [ 1.086026] RSP: 0018:ffa00000048ef998 EFLAGS: 00010286 > [ 1.086166] #PF: supervisor instruction fetch in kernel mode > [ 1.086221] > [ 1.086267] #PF: error_code(0x0011) - permissions violation > [ 1.086321] RAX: ffa00000048efbb8 RBX: ff11000102512cc0 RCX: 000000000000000d > [ 1.086348] PGD 100000067 > [ 1.086394] RDX: ffffffffa06247d0 RSI: ffa00000048efa18 RDI: ff11000102512cc0 > [ 1.086459] P4D 10035f067 > [ 1.086486] RBP: ffa00000048ef9c8 R08: 0000000000000000 R09: 0000000000000007 > [ 1.086550] PUD 100364067 > [ 1.086577] R10: ff110001047d1f08 R11: 00007effdc3d0fff R12: ff110001047d3b00 > [ 1.086641] PMD 441ed9067 > [ 1.086668] R13: ff11000446cae600 R14: ff110001024efe00 R15: ff11000102510a80 > [ 1.086731] PTE 80000004433d3163 > [ 1.086764] FS: 0000000000000000(0000) GS:ff110004aae72000(0000) knlGS:0000000000000000 > [ 1.086829] > [ 1.086868] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 1.086931] Oops: Oops: 0011 [#2] SMP > [ 1.086958] CR2: ffa00000048efbb8 CR3: 0000000102667001 CR4: 0000000000771ef0 > [ 1.087015] CPU: 29 UID: 0 PID: 306 Comm: mount Tainted: G D W E 7.0.0-rc4-virtme-00442-ge53de5a0302f-dirty #85 PREEMPTLAZY > [ 1.087050] PKRU: 55555554 > [ 1.087115] Tainted: [D]=DIE, [W]=WARN, [E]=UNSIGNED_MODULE > [ 1.087207] Kernel panic - not syncing: Fatal exception > [ 2.158392] Shutting down cpus with NMI > [ 2.158629] Kernel Offset: disabled > [ 2.158668] ---[ end Kernel panic - not syncing: Fatal exception ]--- > > It crashes at compat_vma_mmap, and here is what I think could be the > potential crash path: > > - compat_vma_mmap() creates struct vm_area_desc desc; > - compat_set_desc_from_vma Doesn't initialize the struct, but instead > modifies independent fields. I think this is where the behavior > diverges, since before we would use the C initializer and uninitialized Ah yeah you're right I'll fix that up! > variables would be set to 0 (including ommitted ones, like > action.success_hook or action.error_hook). But action.type = MMAP_NOTHING > - desc.action.success_hook remains uninitialized in vfs_mmap_prepare > - mmap_action_complete() > - Here, We've set action.type to be MMAP_NOTHING, so we have err = 0 > - mmap_action_finish(action, vma, 0) > - And here, since err == 0, we check action->success_hook (which has > garbage, therefore it's nonzero) and call action->success_hook(vma) > > And I think action->success_hook(vma) where success_hook is uninitialized > stack garbage gets me to where I am. > > Again, I'm not too familiar with this area of the kernel, this is just > based on the quick digging that I did. And aplogies again if I'm missing > something ; -) I do think that the uninitialized members could be a problem > though. > > Thank you, I hope you have a great day Lorenzo! > Joshua Thanks for the report and analysis, much appreciated, hope you have a great day too :) Cheers, Lorenzo