From: Manas <manas18244@iiitd.ac.in>
To: Peter Xu <peterx@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Anup Sharma <anupnewsmail@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
syzbot+093d096417e7038a689b@syzkaller.appspotmail.com
Subject: Re: [PATCH] Fixes: null pointer dereference in pfnmap_lockdep_assert
Date: Fri, 4 Oct 2024 15:43:12 +0530 [thread overview]
Message-ID: <x4zctv3fdymenonaao2vwsy6ldab6d6pfappdzepfcax6ycc4n@nx46w3lncvqr> (raw)
In-Reply-To: <Zv7JPl_1mxNkvLQy@x1n>
Hi Peter, thanks for reviewing.
On 03.10.2024 12:41, Peter Xu wrote:
>On Thu, Oct 03, 2024 at 09:31:06PM +0530, Manas via B4 Relay wrote:
>> From: Manas <manas18244@iiitd.ac.in>
>>
>> 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 returns if vm_file member in vm_area_struct is NULL.
>>
>> Reported-by: syzbot+093d096417e7038a689b@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=093d096417e7038a689b
>> ---
>> This bug[1] triggers a general protection fault in follow_pfnmap_start
>> function. An assertion pfnmap_lockdep_assert inside this function
>> dereferences vm_file member of vm_area_struct. And panic gets triggered
>> when vm_file is NULL.
>>
>> This patch returns from the assertion pfnmap_lockdep_assert if vm_file
>> is found to be NULL.
>>
>> [1] https://syzkaller.appspot.com/bug?extid=093d096417e7038a689b
>>
>> Signed-off-by: Manas <manas18244@iiitd.ac.in>
>
>Thanks for the patch!
>
>> ---
>> mm/memory.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 2366578015ad..b152a95e543f 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -6346,6 +6346,9 @@ static inline void pfnmap_args_setup(struct follow_pfnmap_args *args,
>> static inline void pfnmap_lockdep_assert(struct vm_area_struct *vma)
>> {
>> #ifdef CONFIG_LOCKDEP
>> + if (!vma->vm_file)
>> + return;
>> +
>
>Hmm I guess I wasn't careful enough here as I was mostly only thinking
>about file mappings, but I just notice we have other pfnmaps like the vvar
>mappings.. the mapping var can also already be reused later when available.
>
>Logically even if !vm_file we can still check against mmap write lock. So
>would it be better to do this instead:
>
> struct address_space *mapping = vma->vm_file && vma->vm_file->f_mapping;
>
This will lead to `-Wint-conversion` error in the assignment. We can either do a
cast like the following:
struct address_space *mapping = (struct address_space *)(vma->vm_file && vma->vm_file->f_mapping);
But I am not sure if it is the canonical way of doing it. It will also lead to
warning about pointer from integer casting.
Or will a conditional like this work here?
struct address_space *mapping = vma->vm_file ? vma->vm_file->f_mapping : NULL;
> if (mapping)
> 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));
>
>?
>
>> struct address_space *mapping = vma->vm_file->f_mapping;
>>
>> if (mapping)
>>
>> ---
>> base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc
>> change-id: 20241003-fix-null-deref-6bfa0337efc3
>>
>> Best regards,
>> --
>> Manas <manas18244@iiitd.ac.in>
>>
>>
>>
>
>--
>Peter Xu
>
--
Manas
next prev parent reply other threads:[~2024-10-04 10:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-03 16:01 Manas via B4 Relay
2024-10-03 16:41 ` Peter Xu
2024-10-04 10:13 ` Manas [this message]
2024-10-04 12:29 ` Peter Xu
2024-10-03 20:31 ` Matthew Wilcox
2024-10-03 21:06 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x4zctv3fdymenonaao2vwsy6ldab6d6pfappdzepfcax6ycc4n@nx46w3lncvqr \
--to=manas18244@iiitd.ac.in \
--cc=akpm@linux-foundation.org \
--cc=anupnewsmail@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=skhan@linuxfoundation.org \
--cc=syzbot+093d096417e7038a689b@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox