lkml.org 
[lkml]   [2021]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [mm] 6128b3af2a: UBSAN:shift-out-of-bounds_in(null)
On 19.10.21 17:49, Eric W. Biederman wrote:
> kernel test robot <oliver.sang@intel.com> writes:
>
>> Greeting,
>>
>> FYI, we noticed the following commit (built with clang-14):
>>
>> commit: 6128b3af2a5e42386aa7faf37609b57f39fb7d00 ("mm: ignore MAP_DENYWRITE in ksys_mmap_pgoff()")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> I believe this failure is misattributed. Perhaps your reproducer
> only intermittently reproduces the problem?
>
> The change in question only contains
>
> flags &= ~MAP_DENYWRITE
>
> After all of the other users of MAP_DENYWRITE had been removed from the
> kernel. So I don't see how it could possibly be responsible for the
> reported shift out of bounds problem.
>
> Eric

Thanks for looking into this Eric while I spent the last couple of days
in bed feeling miserable. :)


So we get 9 new instances of "UBSAN:shift-out-of-bounds_in(null)" (NULL
pointer dereference) on 6128b3af2a compared to 6128b3af2a^ (8d0920bde5),
apparently inside ksys_mmap_pgoff() on 32bit.

As we're dealing with a fuzzer, is there any reproducer as sometimes
provided by syzkaller? The report itself is not very helpful when
judging if that patch is actually responsible for what we're seeing.

I agree with Eric that it's rather unlikely that when we stop masking
off a bit that's ignored throughout the kernel, that we suddenly trigger
a NULL pointer de-reference. But I learned that everything is possible ;)

--
Thanks,

David / dhildenb

\
 
 \ /
  Last update: 2021-10-20 09:23    [W:0.078 / U:1.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site