Re: kernel BUG at mm/memory.c:LINE!

[Dmitry Vyukov]

On Mon, Jul 9, 2018 at 12:15 PM, Kirill A. Shutemov
<kirill@xxxxxxxxxxxxx> wrote:
> On Sun, Jul 08, 2018 at 10:51:03PM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    b2d44d145d2a Merge tag '4.18-rc3-smb3fixes' of git://git.s..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=11d07748400000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=2ca6c7a31d407f86
>> dashboard link: https://syzkaller.appspot.com/bug?extid=3f84280d52be9b7083cc
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+3f84280d52be9b7083cc@xxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> next ffff8801ce5e7040 prev ffff8801d20eca50 mm ffff88019c1e13c0
>> prot 27 anon_vma ffff88019680cdd8 vm_ops 0000000000000000
>> pgoff 0 file ffff8801b2ec2d00 private_data 0000000000000000
>> flags: 0xff(read|write|exec|shared|mayread|maywrite|mayexec|mayshare)
>> ------------[ cut here ]------------
>> kernel BUG at mm/memory.c:1422!
>
> Looks like vma_is_anonymous() false-positive.
>
> Any clues what file is it? I would guess some kind of socket, but it's not
> clear from log which exactly.


>From the log it looks like it was this program (number 3 matches Comm:
syz-executor3):

08:39:32 executing program 3:
r0 = socket$nl_route(0x10, 0x3, 0x0)
bind$netlink(r0, &(0x7f00000002c0)={0x10, 0x0, 0x0, 0x100000}, 0xc)
getsockname(r0, &(0x7f0000000000)=@pppol2tpv3in6={0x0, 0x0, {0x0,
<r1=>0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, {0x0, 0x0, 0x0,
@loopback}}}, &(0x7f00000000c0)=0x3a)
mmap(&(0x7f0000e00000/0x200000)=nil, 0x200000, 0x7fdff, 0x11, r1, 0x0)
ioctl$FIBMAP(r0, 0x1, &(0x7f0000000100)=0x9)
r2 = socket$inet6(0xa, 0x1000000000002, 0x0)
ioctl(r2, 0x8912, &(0x7f00000001c0)="796d05ad441e829115ac7fd77200")
r3 = syz_open_dev$vcsa(&(0x7f0000000140)='/dev/vcsa#\x00', 0x3, 0x2)
ioctl$VHOST_SET_VRING_ENDIAN(r3, 0x4008af13, &(0x7f0000000180)={0x0, 0x8})
sendto$inet(0xffffffffffffffff, &(0x7f0000a88f88), 0xffffffffffffff31,
0x0, &(0x7f0000e68000)={0x2, 0x0, @multicast2=0xe0000002},
0xfffffffffffffeb3)
ftruncate(r1, 0x6)
mmap(&(0x7f0000e00000/0x200000)=nil, 0x200000, 0x0, 0x11, r0, 0x0)
setsockopt$SO_TIMESTAMPING(r1, 0x1, 0x25, &(0x7f0000000080)=0x804, 0x4)

But take what happens here with a grain of salt, it can pretend that
it's doing one thing, but actually do something different.
So that r1 passed to ftruncate is something that getsockname returned
somewhere in the middle of address. And since the socket is not
actually ppp, it can be just some bytes in the middle of netlink
address, that than happened to be small and match some existing fd...