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/fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch
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@xxxxxxxxxxx>
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@xxxxxxxxxxx
Reported-by: syzbot+093d096417e7038a689b@xxxxxxxxxxxxxxxxxxxxxxxxx
Closes: https://syzkaller.appspot.com/bug?extid=093d096417e7038a689b
Cc: Anup Sharma <anupnewsmail@xxxxxxxxx>
Cc: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
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@xxxxxxxxxxx are
fixes-null-pointer-dereference-in-pfnmap_lockdep_assert.patch
