Re: general protection fault in in_aton

[Dmitry Vyukov]

On Wed, Aug 8, 2018 at 8:36 PM, Tomas Bortoli <tomasbortoli@xxxxxxxxx> 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@xxxxxxxxxx>:
>>
>> On Wed, Aug 8, 2018 at 12:43 AM,  <randy.dunlap@xxxxxxxxx> 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...@xxxxxxxxxxxxxxxxxxxx> wrote:
>> >> > On Tue, Jul 10, 2018 at 12:57 PM Dmitry Vyukov <dvy...@xxxxxxxxxx>
>> >> > 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@xxxxxxxxxxxxxxxxx
> 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.