[PATCH v2 12/16] mm: allow handling of stacked mmap_prepare hooks in more drivers
Lorenzo Stoakes (Oracle)
ljs at kernel.org
Thu Mar 19 05:52:22 PDT 2026
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)" <ljs at kernel.org> 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] <TASK>
> [ 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] </TASK>
> [ 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
More information about the linux-afs
mailing list