Re: [syzbot] [mm?] general protection fault in find_mergeable_anon_vma

[Lorenzo Stoakes]

On Mon, Dec 09, 2024 at 02:35:27PM +0100, Jann Horn wrote:
> On Mon, Dec 9, 2024 at 1:53 PM Lorenzo Stoakes
> <lorenzo.stoakes@xxxxxxxxxx> wrote:
> > On Mon, Dec 09, 2024 at 03:20:19AM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    feffde684ac2 Merge tag 'for-6.13-rc1-tag' of git://git.ker..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=17f85fc0580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=50c7a61469ce77e7
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=2d788f4f7cb660dac4b7
> > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Points to this being racey.
> >
> > >
> > > Downloadable assets:
> > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-feffde68.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/6135c7297e8e/vmlinux-feffde68.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/6c154fdcc9cb/bzImage-feffde68.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+2d788f4f7cb660dac4b7@xxxxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000080: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > > KASAN: null-ptr-deref in range [0x0000000000000400-0x0000000000000407]
> >
> > This doesn't make a huge amount of sense to me, the VMA is not 0x400 (1,024)
> > bytes in size... and the actual faulting offset seems to be 0xdffffc0000000080
> > which is 0x80 off from some KASAN-specified value?
>
> If you look at the disassembly, you can see this:
>
>   13: 4d 89 ec              mov    %r13,%r12
>   16: 49 c1 ec 03          shr    $0x3,%r12
>   1a: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
>   21: fc ff df
> * 24: 41 80 3c 04 00        cmpb   $0x0,(%r12,%rax,1) <-- trapping instruction
>
> R13 is 0000000000000406, that's the address we're about to access.
> This code is trying to read KASAN shadow memory for that address by
> reading from 0xdffffc0000000000+address>>3, which for real kernel
> addresses gives you an address in the "KASAN shadow memory" range (see
> https://kernel.org/doc/html/latest/arch/x86/x86_64/mm.html), but for
> addresses in the low half of the address space gives you non-canonical
> addresses starting with 0xdfff that cause #GP on access.
> The second line "KASAN: null-ptr-deref in range
> [0x0000000000000400-0x0000000000000407]" is basically computed by
> doing that calculation in reverse.

Ah thanks.

>
> > This would be vma->vm_file. But that also doesn't really make any sense.
> >
> > But I wonder...
> >
> > I see in the report at [0] that there's a failure injection in vm_area_dup() on
> > fork:
> >
> > [   73.842623][ T5318]  ? kmem_cache_alloc_noprof+0x48/0x380
> > [   73.844725][ T5318]  ? __pfx___might_resched+0x10/0x10
> > [   73.846687][ T5318]  should_fail_ex+0x3b0/0x4e0
> > [   73.848496][ T5318]  should_failslab+0xac/0x100
> > [   73.850232][ T5318]  ? vm_area_dup+0x27/0x290
> > [   73.852017][ T5318]  kmem_cache_alloc_noprof+0x70/0x380
> > [   73.854011][ T5318]  vm_area_dup+0x27/0x290
> > [   73.855771][ T5318]  copy_mm+0xc1d/0x1f90
> >
> > I also see in the fork logic we have the following code on error path:
> >
> >         mas_set_range(&vmi.mas, mpnt->vm_start, mpnt->vm_end - 1);
> >         mas_store(&vmi.mas, XA_ZERO_ENTRY);
> >
> > And XA_ZERO_ENTRY is 0x406.
>
> That matches...

And I wasn't aware that R13 was equal to the _actual_ address derefenced,
really useful to know, I mentioned it in my mega reply where I figured out
how we end up trying to deref this... :) yes I think this confirms the
theory.