general protection fault in in_aton

general protection fault in in_aton

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:    092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1687b168400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
dashboard link: https://syzkaller.appspot.com/bug?extid=2a831e062bb4aebd8755
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=158cc2c2400000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16e7ef48400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4524 Comm: syz-executor617 Not tainted 4.18.0-rc4+ #42
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63
Code: f6 41 55 41 54 49 89 fc 53 48 83 ec 08 c7 45 d4 00 00 00 00 e8 a3 a5  
7c fb 4c 89 e0 4c 89 e2 c1 65 d4 08 48 c1 e8 03 83 e2 07 <42> 0f b6 04 38  
38 d0 7f 08 84 c0 0f 85 1a 01 00 00 41 0f be 1c 24
RSP: 0018:ffff8801a8f171a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801acc613a4 RCX: ffffffff87685d49
RDX: 0000000000000000 RSI: ffffffff85ff65fd RDI: 0000000000000000
RBP: ffff8801a8f171d0 R08: ffff8801ac928040 R09: ffffed00351e2df9
R10: ffffed00351e2df9 R11: 0000000000000003 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff8801dae00000(0063) knlGS:000000000961b840
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000020000140 CR3: 00000001ac93c000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  rdma_create_trans+0xdbe/0x1ed0 net/9p/trans_rdma.c:678
  p9_client_create+0x915/0x16c9 net/9p/client.c:1062
  v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
  v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
  mount_fs+0xae/0x328 fs/super.c:1277
  vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
  vfs_kern_mount fs/namespace.c:1027 [inline]
  do_new_mount fs/namespace.c:2518 [inline]
  do_mount+0x581/0x30e0 fs/namespace.c:2848
  __do_compat_sys_mount fs/compat.c:125 [inline]
  __se_compat_sys_mount fs/compat.c:92 [inline]
  __ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92
  do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
  do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f65cb9
Code: 55 08 8b 88 64 cd ff ff 8b 98 68 cd ff ff 89 c8 85 d2 74 02 89 0a 5b  
5d c3 8b 04 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90  
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000ffb9d3bc EFLAGS: 00000282 ORIG_RAX: 0000000000000015
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000200000c0
RDX: 0000000020000340 RSI: 0000000000000000 RDI: 0000000020000180
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
    (ftrace buffer empty)
---[ end trace 5db7de5a7d39bf0a ]---
RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63
Code: f6 41 55 41 54 49 89 fc 53 48 83 ec 08 c7 45 d4 00 00 00 00 e8 a3 a5  
7c fb 4c 89 e0 4c 89 e2 c1 65 d4 08 48 c1 e8 03 83 e2 07 <42> 0f b6 04 38  
38 d0 7f 08 84 c0 0f 85 1a 01 00 00 41 0f be 1c 24
RSP: 0018:ffff8801a8f171a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801acc613a4 RCX: ffffffff87685d49
RDX: 0000000000000000 RSI: ffffffff85ff65fd RDI: 0000000000000000
RBP: ffff8801a8f171d0 R08: ffff8801ac928040 R09: ffffed00351e2df9
R10: ffffed00351e2df9 R11: 0000000000000003 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff8801dae00000(0063) knlGS:000000000961b840
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000020000140 CR3: 00000001ac93c000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: general protection fault in in_aton

[Linus Torvalds]

On Tue, Jul 10, 2018 at 12:19 PM syzbot
<syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com> wrote:
> RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63

That's

                if (*str != '\0') {

in in_aton().

The code disassembles to

        movzbl (%rax,%r15,1),%eax

which is a bit odd, because

> RAX: 0000000000000000

Ok, NULL pointer, looks sane, but:

> R15: dffffc0000000000

Yeah, that's unusual. But I'm guessing it's some KASAN artifact. One
of the big problemns with KASAN is that it makes the generated code
completely illegible because 90% of the code is just KASAN overhead.

> Call Trace:
>   rdma_create_trans+0xdbe/0x1ed0 net/9p/trans_rdma.c:678

Well, rdma_create_trans() certainly doesn't verify 'addr' before using it.

>   p9_client_create+0x915/0x16c9 net/9p/client.c:1062

p9_client_create() just blindly passes on "dev_name"

>   v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
>   v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135

.. as does v9fs_session_init() and v9fs_mount()

>   mount_fs+0xae/0x328 fs/super.c:1277
>   vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
>   vfs_kern_mount fs/namespace.c:1027 [inline]
>   do_new_mount fs/namespace.c:2518 [inline]
>   do_mount+0x581/0x30e0 fs/namespace.c:2848

This is "name" in mount_fs(), vfs_kern_mount(), do_new_mount() and
do_mount(), also just passed through.

>   __do_compat_sys_mount fs/compat.c:125 [inline]
>   __se_compat_sys_mount fs/compat.c:92 [inline]
>   __ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92

And here we have the source:

        kernel_dev = copy_mount_string(dev_name);

Note that copy_mount_string() just passes a NULL user space pointer
through as a NULL kernel pointer (otherwise it does a
"strndup_user()".

And no, this is not a compat issue. The native mount does the same thing.

So yes. The device name can trivially be NULL, and either rdma or the
p9 code should check for NULL.

Adding in the 9p people, because I think it's for them. Note the
syzbot info below.

               Linus

--

syzbot found the following crash on:

HEAD commit:    092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1687b168400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
dashboard link: https://syzkaller.appspot.com/bug?extid=2a831e062bb4aebd8755
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=158cc2c2400000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16e7ef48400000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com

Re: general protection fault in in_aton

[Dmitry Vyukov]

On Tue, Jul 10, 2018 at 9:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jul 10, 2018 at 12:19 PM syzbot
> <syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com> wrote:
>> RIP: 0010:in_aton+0x3e/0x180 net/core/utils.c:63
>
> That's
>
>                 if (*str != '\0') {
>
> in in_aton().
>
> The code disassembles to
>
>         movzbl (%rax,%r15,1),%eax
>
> which is a bit odd, because
>
>> RAX: 0000000000000000
>
> Ok, NULL pointer, looks sane, but:
>
>> R15: dffffc0000000000
>
> Yeah, that's unusual. But I'm guessing it's some KASAN artifact. One
> of the big problemns with KASAN is that it makes the generated code
> completely illegible because 90% of the code is just KASAN overhead.


Yes, there is a problem with paging faults under KASAN.
For more complex bugs like use-after-frees and out-of-bounds there is
usually no need to look at disasm at all because KASAN provides all
relevant info in the report (actual access address, object start,
object size, where is was allocated/freed). But for paging faults
(notably NULL derefs), that's handled by the standard handler which
does not know about KASAN (except for printing "kasan: GPF could be
caused by NULL-ptr deref or user memory access"). Long time ago I
asked if it's possible to get the fault address in the handler, but I
got reply that it's close to impossible.

What KASAN does is reasonably simple: before each access to address
ADDR it inserts:

if (*(0xdffffc0000000000 + ADDR/8))
        report_error();
... *ADDR ... // original access

So if we would have the fault address, and we see that it's
[0xdffffc0000000000; 0xdffffc0000000000+PAGE_SIZE/8), then we could
simply say that it's NULL deref.

Is it really hard to get fault address? I know that userspace
generally receives fault address in siginfo.


>> Call Trace:
>>   rdma_create_trans+0xdbe/0x1ed0 net/9p/trans_rdma.c:678
>
> Well, rdma_create_trans() certainly doesn't verify 'addr' before using it.
>
>>   p9_client_create+0x915/0x16c9 net/9p/client.c:1062
>
> p9_client_create() just blindly passes on "dev_name"
>
>>   v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
>>   v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
>
> .. as does v9fs_session_init() and v9fs_mount()
>
>>   mount_fs+0xae/0x328 fs/super.c:1277
>>   vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
>>   vfs_kern_mount fs/namespace.c:1027 [inline]
>>   do_new_mount fs/namespace.c:2518 [inline]
>>   do_mount+0x581/0x30e0 fs/namespace.c:2848
>
> This is "name" in mount_fs(), vfs_kern_mount(), do_new_mount() and
> do_mount(), also just passed through.
>
>>   __do_compat_sys_mount fs/compat.c:125 [inline]
>>   __se_compat_sys_mount fs/compat.c:92 [inline]
>>   __ia32_compat_sys_mount+0x5d5/0x860 fs/compat.c:92
>
> And here we have the source:
>
>         kernel_dev = copy_mount_string(dev_name);
>
> Note that copy_mount_string() just passes a NULL user space pointer
> through as a NULL kernel pointer (otherwise it does a
> "strndup_user()".
>
> And no, this is not a compat issue. The native mount does the same thing.
>
> So yes. The device name can trivially be NULL, and either rdma or the
> p9 code should check for NULL.
>
> Adding in the 9p people, because I think it's for them. Note the
> syzbot info below.
>
>                Linus
>
> --
>
> syzbot found the following crash on:
>
> HEAD commit:    092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1687b168400000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
> dashboard link: https://syzkaller.appspot.com/bug?extid=2a831e062bb4aebd8755
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> userspace arch: i386
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=158cc2c2400000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16e7ef48400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+2a831e062bb4aebd8755@syzkaller.appspotmail.com
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CA%2B55aFyEZR%3Dv2GySzWWF3uh9ZB53CFFv460Wzg4n8DGze8GFfw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: general protection fault in in_aton

[Linus Torvalds]

On Tue, Jul 10, 2018 at 12:57 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> Is it really hard to get fault address? I know that userspace
> generally receives fault address in siginfo.

For an actual page fault it's trivial.

However, for invalid addresses (aka "non-canonical"), you don't even
get a page fault, you get a GP like in this case. And then the actual
address is not available.

                 Linus

Re: general protection fault in in_aton

[Dmitry Vyukov]

On Tue, Jul 10, 2018 at 10:15 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jul 10, 2018 at 12:57 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>>
>> Is it really hard to get fault address? I know that userspace
>> generally receives fault address in siginfo.
>
> For an actual page fault it's trivial.
>
> However, for invalid addresses (aka "non-canonical"), you don't even
> get a page fault, you get a GP like in this case. And then the actual
> address is not available.


I see. Then I don't have any great ideas. Running without KASAN would
result in more, much more cryptic crashes.

FWIW for these "GPF could be caused by NULL-ptr deref" I first just
assume that it's in fact a NULL deref. And in this case it all pretty
quickly forms a consistent picture that it's indeed just a missing a
NULL pointer check. That dffffc0000000000 in a register also a good
hint.

Re: general protection fault in in_aton

[Dmitry Vyukov]

On Wed, Aug 8, 2018 at 12:43 AM,  <randy.dunlap@gmail.com> wrote:
>
>
> On Wednesday, July 11, 2018 at 9:48:02 AM UTC-7, Dmitry Vyukov wrote:
>>
>> On Tue, Jul 10, 2018 at 10:15 PM, Linus Torvalds
>> <torv...@linux-foundation.org> wrote:
>> > On Tue, Jul 10, 2018 at 12:57 PM Dmitry Vyukov <dvy...@google.com>
>> > wrote:
>> >>
>> >> Is it really hard to get fault address? I know that userspace
>> >> generally receives fault address in siginfo.
>> >
>> > For an actual page fault it's trivial.
>> >
>> > However, for invalid addresses (aka "non-canonical"), you don't even
>> > get a page fault, you get a GP like in this case. And then the actual
>> > address is not available.
>>
>>
>> I see. Then I don't have any great ideas. Running without KASAN would
>> result in more, much more cryptic crashes.
>>
>> FWIW for these "GPF could be caused by NULL-ptr deref" I first just
>> assume that it's in fact a NULL deref. And in this case it all pretty
>> quickly forms a consistent picture that it's indeed just a missing a
>> NULL pointer check. That dffffc0000000000 in a register also a good
>> hint.
>
>
> The second mount syscall in loop() has a pointer parameter of 0 (null):
>       syscall(__NR_mount, 0, 0x200000c0, 0x20000340, 0, 0x20000180);
> and that NULL is passed from do_mount() to do_new_mount() to
> vfs_kern_mount()
> on to mount_fs() to v9fs_mount() to v9fs_session_init() to
> p9_client_create() to
> rdma_create_trans() and then to in_aton().  Are all of those valid up until
> the
> call to in_aton()?

Hi Randy,

+kernel mailing lists again

Please keep kernel lists and developers and CC, there are no kernel
developers on syzkaller-bugs@ list.

This is almost the same as "general protection fault in
p9_fd_create_unix" just for rdma:
https://syzkaller.appspot.com/bug?extid=1a262da37d3bead15c39
Yes, this function needs to check for NULL.

Tomas, I think it makes sense to include rdma into your "9p: fix NULL
pointer dereferences" patch.

Re: general protection fault in in_aton

[Dmitry Vyukov]

On Wed, Aug 8, 2018 at 8:36 PM, Tomas Bortoli <tomasbortoli@gmail.com> wrote:
> Hi Dmitry,
>
> This patch has already rdma in:
>
> https://lkml.org/lkml/2018/7/27/484
>
> Sorry I forgot to flag the v2.

Ah, great!

Then let's mark this bug as a dup of that one:

#syz dup: general protection fault in p9_fd_create_unix


> 2018-08-08 17:56 GMT+02:00 Dmitry Vyukov <dvyukov@google.com>:
>>
>> On Wed, Aug 8, 2018 at 12:43 AM,  <randy.dunlap@gmail.com> wrote:
>> >
>> >
>> > On Wednesday, July 11, 2018 at 9:48:02 AM UTC-7, Dmitry Vyukov wrote:
>> >>
>> >> On Tue, Jul 10, 2018 at 10:15 PM, Linus Torvalds
>> >> <torv...@linux-foundation.org> wrote:
>> >> > On Tue, Jul 10, 2018 at 12:57 PM Dmitry Vyukov <dvy...@google.com>
>> >> > wrote:
>> >> >>
>> >> >> Is it really hard to get fault address? I know that userspace
>> >> >> generally receives fault address in siginfo.
>> >> >
>> >> > For an actual page fault it's trivial.
>> >> >
>> >> > However, for invalid addresses (aka "non-canonical"), you don't even
>> >> > get a page fault, you get a GP like in this case. And then the actual
>> >> > address is not available.
>> >>
>> >>
>> >> I see. Then I don't have any great ideas. Running without KASAN would
>> >> result in more, much more cryptic crashes.
>> >>
>> >> FWIW for these "GPF could be caused by NULL-ptr deref" I first just
>> >> assume that it's in fact a NULL deref. And in this case it all pretty
>> >> quickly forms a consistent picture that it's indeed just a missing a
>> >> NULL pointer check. That dffffc0000000000 in a register also a good
>> >> hint.
>> >
>> >
>> > The second mount syscall in loop() has a pointer parameter of 0 (null):
>> >       syscall(__NR_mount, 0, 0x200000c0, 0x20000340, 0, 0x20000180);
>> > and that NULL is passed from do_mount() to do_new_mount() to
>> > vfs_kern_mount()
>> > on to mount_fs() to v9fs_mount() to v9fs_session_init() to
>> > p9_client_create() to
>> > rdma_create_trans() and then to in_aton().  Are all of those valid up
>> > until
>> > the
>> > call to in_aton()?
>>
>> Hi Randy,
>>
>> +kernel mailing lists again
>>
>> Please keep kernel lists and developers and CC, there are no kernel
>> developers on syzkaller-bugs@ list.
>>
>> This is almost the same as "general protection fault in
>> p9_fd_create_unix" just for rdma:
>> https://syzkaller.appspot.com/bug?extid=1a262da37d3bead15c39
>> Yes, this function needs to check for NULL.
>>
>> Tomas, I think it makes sense to include rdma into your "9p: fix NULL
>> pointer dereferences" patch.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/CAAHj5qiQNOfD2c_xHw4sqQOGR3BNvYGncdg2fdgogcFz9u5peA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.