The patch titled Subject: mm: fix null pointer dereference in pfnmap_lockdep_assert has been added to the -mm mm-hotfixes-unstable branch. Its filename is fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch
This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches...
This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days
------------------------------------------------------ From: Manas manas18244@iiitd.ac.in Subject: mm: fix null pointer dereference in pfnmap_lockdep_assert Date: Fri, 04 Oct 2024 23:12:16 +0530
syzbot has pointed to a possible null pointer dereference in pfnmap_lockdep_assert. vm_file member of vm_area_struct is being dereferenced without any checks.
This fix assigns mapping only if vm_file is not NULL.
Peter said (https://lkml.kernel.org/r/Zv8HRA5mnhVevBN_@x1n):
: If I read the stack right, the crash was before mmap() of the new vma : happens, instead it's during unmap() of one existing vma which existed and : overlapped with the new vma's mapping range: : : follow_phys arch/x86/mm/pat/memtype.c:956 [inline] : get_pat_info+0x182/0x3f0 arch/x86/mm/pat/memtype.c:988 : untrack_pfn+0x327/0x640 arch/x86/mm/pat/memtype.c:1101 : unmap_single_vma+0x1f6/0x2b0 mm/memory.c:1834 : unmap_vmas+0x3cc/0x5f0 mm/memory.c:1900 : unmap_region+0x214/0x380 mm/vma.c:354 <--------------- here : mmap_region+0x22f9/0x2990 mm/mmap.c:1573 : do_mmap+0x8f0/0x1000 mm/mmap.c:496 : vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:588 : ksys_mmap_pgoff+0x4eb/0x720 mm/mmap.c:542 : do_syscall_x64 arch/x86/entry/common.c:52 [inline] : do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 : entry_SYSCALL_64_after_hwframe+0x77/0x7f : : It looks like the vma that was overwritten by the new file vma mapping : could be a VM_PFNMAP vma (I'm guessing vvar or something similar..), : that's where untrack_pfn() got kicked off. In this case, the vma being : overwritten and to be unmapped can have ->vm_file==NULL (while ->vm_ops : non-NULL; /me looking at __install_special_mapping()).
Link: https://lkml.kernel.org/r/20241004-fix-null-deref-v4-1-d0a8ec01ac85@iiitd.ac... Reported-by: syzbot+093d096417e7038a689b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=093d096417e7038a689b Cc: Anup Sharma anupnewsmail@gmail.com Cc: Shuah Khan skhan@linuxfoundation.org Cc: Matthew Wilcox willy@infradead.org Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
mm/memory.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
--- a/mm/memory.c~fixes-null-pointer-dereference-in-pfnmap_lockdep_assert +++ a/mm/memory.c @@ -6355,10 +6355,13 @@ static inline void pfnmap_args_setup(str static inline void pfnmap_lockdep_assert(struct vm_area_struct *vma) { #ifdef CONFIG_LOCKDEP - struct address_space *mapping = vma->vm_file->f_mapping; + struct address_space *mapping = NULL; + + if (vma->vm_file) + mapping = vma->vm_file->f_mapping;
if (mapping) - lockdep_assert(lockdep_is_held(&vma->vm_file->f_mapping->i_mmap_rwsem) || + lockdep_assert(lockdep_is_held(&mapping->i_mmap_rwsem) || lockdep_is_held(&vma->vm_mm->mmap_lock)); else lockdep_assert(lockdep_is_held(&vma->vm_mm->mmap_lock)); _
Patches currently in -mm which might be from manas18244@iiitd.ac.in are
fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch