Re: general protection fault in sctp_sched_prio_sched

Re: general protection fault in sctp_sched_prio_sched

[Marcelo Ricardo Leitner]

On Tue, Jun 18, 2019 at 10:45:54PM +0800, Hillf Danton wrote:
...
> > Anyway, with the patch above, after calling
> > sctp_stream_init_ext() ->ext will be either completely valid, or it
> > will not be present at all as it is seting ->ext to NULL if sid
> > initialization ended up failing.
> > 
> Correct with no doubt.
> 
> I was wondering if it is likely for the ->ext, loaded with a valid slab,
> to cause a gpf in sctp_sched_prio_sched() without your patch applied.
> And if the failure to initialise sid could likely change the result.

Thanks, I think I understand now. Well, without the patch, yes, as
syzbot reported. Seems you're also worried if it can happen in other
situations as well, and end up triggering the same gpf but on a
different situation. I don't think so. It should be either
initialized or not initialized. Half-initialized as it was, that's a
pain.

  Marcelo

Re: general protection fault in sctp_sched_prio_sched

[Marcelo Ricardo Leitner]

Hi,

On Tue, Jun 18, 2019 at 04:04:01PM +0800, Hillf Danton wrote:
> 
> Hello Marcelo
> 
> On Mon, 17 Jun 2019 22:43:38 +0800 Marcelo Ricardo Leitner wrote:
> > On Mon, Jun 17, 2019 at 10:49:13AM -0300, Marcelo Ricardo Leitner wrote:
> > > Hi,
> > >
> > > On Sun, Jun 16, 2019 at 11:38:03PM +0800, Hillf Danton wrote:
> > > >
> > > > Hello Syzbot
> > > >
> > > > On Sat, 15 Jun 2019 16:36:06 -0700 (PDT) syzbot wrote:
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > ...
> > > > Check prio_head and bail out if it is not valid.
> > > >
> > > > Thanks
> > > > Hillf
> > > > ----->8---
> > > > ---
> > > > net/sctp/stream_sched_prio.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/net/sctp/stream_sched_prio.c b/net/sctp/stream_sched_prio.c
> > > > index 2245083..db25a43 100644
> > > > --- a/net/sctp/stream_sched_prio.c
> > > > +++ b/net/sctp/stream_sched_prio.c
> > > > @@ -135,6 +135,8 @@ static void sctp_sched_prio_sched(struct sctp_stream *stream,
> > > > 	struct sctp_stream_priorities *prio, *prio_head;
> > > >
> > > > 	prio_head = soute->prio_head;
> > > > +	if (!prio_head)
> > > > +		return;
> > > >
> > > > 	/* Nothing to do if already scheduled */
> > > > 	if (!list_empty(&soute->prio_list))
> > > > --
> > >
> > > Thanks but this is not a good fix for this. It will cause the stream
> > > to never be scheduled.
> > >
> Thanks very much for the light you are casting.
> 
> > > The problem happens because of the fault injection that happened a bit
> > > before the crash, in here:
> > >
> > > int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
> > > {
> > >         struct sctp_stream_out_ext *soute;
> > >
> > >         soute = kzalloc(sizeof(*soute), GFP_KERNEL);
> > >         if (!soute)
> > >                 return -ENOMEM;
> > >         SCTP_SO(stream, sid)->ext = soute;  <---- [A]
> > >
> > >         return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
> > >                       ^^^^^^^^^^^^---- [B] failed
> > > }
> > >
> Eagle eye.
> 
> > > This causes the 1st sendmsg to bail out with the error. When the 2nd
> > > one gets in, it will:
> > >
> > > sctp_sendmsg_to_asoc()
> > > {
> > > ...
> > >         if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > >                                                                  ^^^^^--- [C]
> > >                 err = sctp_stream_init_ext(&asoc->stream, sinfo->sinfo_stream);
> > >                 if (err)
> > >                         goto err;
> > >         }
> > >
> > > [A] leaves ext initialized, despite the failed in [B]. Then in [C], it
> > > will not try to initialize again.
> > >
> Fairly concise.
> 
> > > We need to either uninitialize ->ext as error handling for [B], or
> > > improve the check on [C].
> > 
> > The former one, please. This should be enough (untested):
> > 
> > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > index 93ed07877337..25946604af85 100644
> > --- a/net/sctp/stream.c
> > +++ b/net/sctp/stream.c
> > @@ -153,13 +153,20 @@ int sctp_stream_init(struct sctp_stream *stream, __u1=
> > 6 outcnt, __u16 incnt,
> >  int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
> >  {
> >  	struct sctp_stream_out_ext *soute;
> > +	int ret;
> > 
> >  	soute = kzalloc(sizeof(*soute), GFP_KERNEL);
> >  	if (!soute)
> >  		return -ENOMEM;
> >  	SCTP_SO(stream, sid)->ext = soute;
> > 
> > -	return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
> > +	ret = sctp_sched_init_sid(stream, sid, GFP_KERNEL);
> > +	if (ret) {
> > +		kfree(SCTP_SO(stream, sid)->ext);
> > +		SCTP_SO(stream, sid)->ext = NULL;

[D]

> > +	}
> > +
> > +	return ret;
> >  }
> > 
> Definitely nice.
> 
> >  void sctp_stream_free(struct sctp_stream *stream)
> > 
> Hmmm, ->ext will be valid, provided it is loaded with a valid slab in
> sctp_stream_init_ext() regardless of whether sid is successfully
> initialised, until it is released, for instance, in sctp_stream_free(),
> and based on that assumption, it looks hardly likely that ->ext has a
> chance to create a gfp in sctp_sched_prio_sched().

I'm not sure I follow you. Anyway, with the patch above, after calling
sctp_stream_init_ext() ->ext will be either completely valid, or it
will not be present at all as it is seting ->ext to NULL if sid
initialization ended up failing.

  Marcelo

Re: general protection fault in sctp_sched_prio_sched

[Marcelo Ricardo Leitner]

Hi,

On Sun, Jun 16, 2019 at 11:38:03PM +0800, Hillf Danton wrote:
> 
> Hello Syzbot
> 
> On Sat, 15 Jun 2019 16:36:06 -0700 (PDT) syzbot wrote:
> > Hello,
> > 
> > syzbot found the following crash on:
> > 
...
> Check prio_head and bail out if it is not valid.
> 
> Thanks
> Hillf
> ----->8---
> ---
> net/sctp/stream_sched_prio.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/net/sctp/stream_sched_prio.c b/net/sctp/stream_sched_prio.c
> index 2245083..db25a43 100644
> --- a/net/sctp/stream_sched_prio.c
> +++ b/net/sctp/stream_sched_prio.c
> @@ -135,6 +135,8 @@ static void sctp_sched_prio_sched(struct sctp_stream *stream,
> 	struct sctp_stream_priorities *prio, *prio_head;
> 
> 	prio_head = soute->prio_head;
> +	if (!prio_head)
> +		return;
> 
> 	/* Nothing to do if already scheduled */
> 	if (!list_empty(&soute->prio_list))
> --

Thanks but this is not a good fix for this. It will cause the stream
to never be scheduled.

The problem happens because of the fault injection that happened a bit
before the crash, in here:

int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
{
        struct sctp_stream_out_ext *soute;

        soute = kzalloc(sizeof(*soute), GFP_KERNEL);
        if (!soute)
                return -ENOMEM;
        SCTP_SO(stream, sid)->ext = soute;  <---- [A]

        return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
                      ^^^^^^^^^^^^---- [B] failed
}

This causes the 1st sendmsg to bail out with the error. When the 2nd
one gets in, it will:

sctp_sendmsg_to_asoc()
{
...
        if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
                                                                 ^^^^^--- [C]
                err = sctp_stream_init_ext(&asoc->stream, sinfo->sinfo_stream);
                if (err)
                        goto err;
        }

[A] leaves ext initialized, despite the failed in [B]. Then in [C], it
will not try to initialize again.

We need to either uninitialize ->ext as error handling for [B], or
improve the check on [C].

syzbot++ once again.

  Marcelo

Re: general protection fault in sctp_sched_prio_sched

[Marcelo Ricardo Leitner]

On Mon, Jun 17, 2019 at 10:49:13AM -0300, Marcelo Ricardo Leitner wrote:
> Hi,
> 
> On Sun, Jun 16, 2019 at 11:38:03PM +0800, Hillf Danton wrote:
> > 
> > Hello Syzbot
> > 
> > On Sat, 15 Jun 2019 16:36:06 -0700 (PDT) syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following crash on:
> > > 
> ...
> > Check prio_head and bail out if it is not valid.
> > 
> > Thanks
> > Hillf
> > ----->8---
> > ---
> > net/sctp/stream_sched_prio.c | 2 ++
> > 1 file changed, 2 insertions(+)
> > 
> > diff --git a/net/sctp/stream_sched_prio.c b/net/sctp/stream_sched_prio.c
> > index 2245083..db25a43 100644
> > --- a/net/sctp/stream_sched_prio.c
> > +++ b/net/sctp/stream_sched_prio.c
> > @@ -135,6 +135,8 @@ static void sctp_sched_prio_sched(struct sctp_stream *stream,
> > 	struct sctp_stream_priorities *prio, *prio_head;
> > 
> > 	prio_head = soute->prio_head;
> > +	if (!prio_head)
> > +		return;
> > 
> > 	/* Nothing to do if already scheduled */
> > 	if (!list_empty(&soute->prio_list))
> > --
> 
> Thanks but this is not a good fix for this. It will cause the stream
> to never be scheduled.
> 
> The problem happens because of the fault injection that happened a bit
> before the crash, in here:
> 
> int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
> {
>         struct sctp_stream_out_ext *soute;
> 
>         soute = kzalloc(sizeof(*soute), GFP_KERNEL);
>         if (!soute)
>                 return -ENOMEM;
>         SCTP_SO(stream, sid)->ext = soute;  <---- [A]
> 
>         return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
>                       ^^^^^^^^^^^^---- [B] failed
> }
> 
> This causes the 1st sendmsg to bail out with the error. When the 2nd
> one gets in, it will:
> 
> sctp_sendmsg_to_asoc()
> {
> ...
>         if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
>                                                                  ^^^^^--- [C]
>                 err = sctp_stream_init_ext(&asoc->stream, sinfo->sinfo_stream);
>                 if (err)
>                         goto err;
>         }
> 
> [A] leaves ext initialized, despite the failed in [B]. Then in [C], it
> will not try to initialize again.
> 
> We need to either uninitialize ->ext as error handling for [B], or
> improve the check on [C].

The former one, please. This should be enough (untested):

diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index 93ed07877337..25946604af85 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -153,13 +153,20 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
 int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
 {
 	struct sctp_stream_out_ext *soute;
+	int ret;
 
 	soute = kzalloc(sizeof(*soute), GFP_KERNEL);
 	if (!soute)
 		return -ENOMEM;
 	SCTP_SO(stream, sid)->ext = soute;
 
-	return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
+	ret = sctp_sched_init_sid(stream, sid, GFP_KERNEL);
+	if (ret) {
+		kfree(SCTP_SO(stream, sid)->ext);
+		SCTP_SO(stream, sid)->ext = NULL;
+	}
+
+	return ret;
 }
 
 void sctp_stream_free(struct sctp_stream *stream)

Re: general protection fault in sctp_sched_prio_sched

[Xin Long]

On Mon, Jun 17, 2019 at 10:43 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Mon, Jun 17, 2019 at 10:49:13AM -0300, Marcelo Ricardo Leitner wrote:
> > Hi,
> >
> > On Sun, Jun 16, 2019 at 11:38:03PM +0800, Hillf Danton wrote:
> > >
> > > Hello Syzbot
> > >
> > > On Sat, 15 Jun 2019 16:36:06 -0700 (PDT) syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > ...
> > > Check prio_head and bail out if it is not valid.
> > >
> > > Thanks
> > > Hillf
> > > ----->8---
> > > ---
> > > net/sctp/stream_sched_prio.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/net/sctp/stream_sched_prio.c b/net/sctp/stream_sched_prio.c
> > > index 2245083..db25a43 100644
> > > --- a/net/sctp/stream_sched_prio.c
> > > +++ b/net/sctp/stream_sched_prio.c
> > > @@ -135,6 +135,8 @@ static void sctp_sched_prio_sched(struct sctp_stream *stream,
> > >     struct sctp_stream_priorities *prio, *prio_head;
> > >
> > >     prio_head = soute->prio_head;
> > > +   if (!prio_head)
> > > +           return;
> > >
> > >     /* Nothing to do if already scheduled */
> > >     if (!list_empty(&soute->prio_list))
> > > --
> >
> > Thanks but this is not a good fix for this. It will cause the stream
> > to never be scheduled.
> >
> > The problem happens because of the fault injection that happened a bit
> > before the crash, in here:
> >
> > int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
> > {
> >         struct sctp_stream_out_ext *soute;
> >
> >         soute = kzalloc(sizeof(*soute), GFP_KERNEL);
> >         if (!soute)
> >                 return -ENOMEM;
> >         SCTP_SO(stream, sid)->ext = soute;  <---- [A]
> >
> >         return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
> >                       ^^^^^^^^^^^^---- [B] failed
> > }
> >
> > This causes the 1st sendmsg to bail out with the error. When the 2nd
> > one gets in, it will:
> >
> > sctp_sendmsg_to_asoc()
> > {
> > ...
> >         if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> >                                                                  ^^^^^--- [C]
> >                 err = sctp_stream_init_ext(&asoc->stream, sinfo->sinfo_stream);
> >                 if (err)
> >                         goto err;
> >         }
> >
> > [A] leaves ext initialized, despite the failed in [B]. Then in [C], it
> > will not try to initialize again.
> >
> > We need to either uninitialize ->ext as error handling for [B], or
> > improve the check on [C].
>
> The former one, please. This should be enough (untested):
>
> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> index 93ed07877337..25946604af85 100644
> --- a/net/sctp/stream.c
> +++ b/net/sctp/stream.c
> @@ -153,13 +153,20 @@ int sctp_stream_init(struct sctp_stream *stream, __u16 outcnt, __u16 incnt,
>  int sctp_stream_init_ext(struct sctp_stream *stream, __u16 sid)
>  {
>         struct sctp_stream_out_ext *soute;
> +       int ret;
>
>         soute = kzalloc(sizeof(*soute), GFP_KERNEL);
>         if (!soute)
>                 return -ENOMEM;
>         SCTP_SO(stream, sid)->ext = soute;
>
> -       return sctp_sched_init_sid(stream, sid, GFP_KERNEL);
> +       ret = sctp_sched_init_sid(stream, sid, GFP_KERNEL);
> +       if (ret) {
> +               kfree(SCTP_SO(stream, sid)->ext);
> +               SCTP_SO(stream, sid)->ext = NULL;
> +       }
> +
> +       return ret;
>  }
>
>  void sctp_stream_free(struct sctp_stream *stream)
>

Tested-by: Xin Long <lucien.xin@gmail.com>

Hi, Marcelo, please feel free to move forward with this patch, :-)

general protection fault in sctp_sched_prio_sched

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:    35fc07ae Merge branch 'tcp-add-three-static-keys'
git tree:       net
console output: https://syzkaller.appspot.com/x/log.txt?x=118e5caea00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e8b7a9cd7feeb720
dashboard link: https://syzkaller.appspot.com/bug?extid=c1a380d42b190ad1e559
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11551df1a00000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12417076a00000

The bug was bisected to:

commit 4ff40b86262b73553ee47cc3784ce8ba0f220bd8
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Jan 21 18:42:09 2019 +0000

     sctp: set chunk transport correctly when it's a new asoc

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=104d1df1a00000
final crash:    https://syzkaller.appspot.com/x/report.txt?x=124d1df1a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=144d1df1a00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c1a380d42b190ad1e559@syzkaller.appspotmail.com
Fixes: 4ff40b86262b ("sctp: set chunk transport correctly when it's a new  
asoc")

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8330 Comm: syz-executor666 Not tainted 5.2.0-rc3+ #52
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:sctp_sched_prio_sched+0x96/0x6f0 net/sctp/stream_sched_prio.c:132
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 0d 05 00 00 48 b8 00 00 00 00  
00 fc ff df 4c 8b 73 50 4d 8d 6e 20 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f  
85 f4 04 00 00 4d 8b 7e 20 4d 85 ff 0f 84 f8 00 00
RSP: 0018:ffff88809e4e7448 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8880a9533b80 RCX: 1ffff11010347201
RDX: 0000000000000004 RSI: ffffffff8696a77e RDI: ffff8880a9533bd0
RBP: ffff88809e4e7488 R08: ffff88808bf8e300 R09: ffff88809e4e7580
R10: ffffed1013c9cee2 R11: 0000000000000003 R12: ffff8880a9533bc0
R13: 0000000000000020 R14: 0000000000000000 R15: ffff8880a4e92380
FS:  00007f48c9337700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f48c9315e78 CR3: 000000009db54000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  sctp_sched_prio_enqueue+0x117/0x170 net/sctp/stream_sched_prio.c:243
  sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1101 [inline]
  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1748 [inline]
  sctp_side_effects net/sctp/sm_sideeffect.c:1184 [inline]
  sctp_do_sm+0x2fd0/0x5190 net/sctp/sm_sideeffect.c:1155
  sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:163
  sctp_sendmsg_to_asoc+0x1118/0x1f10 net/sctp/socket.c:1944
  sctp_sendmsg+0x109a/0x17d0 net/sctp/socket.c:2102
  inet_sendmsg+0x141/0x5d0 net/ipv4/af_inet.c:798
  sock_sendmsg_nosec net/socket.c:646 [inline]
  sock_sendmsg+0xd7/0x130 net/socket.c:665
  sock_write_iter+0x27c/0x3e0 net/socket.c:994
  call_write_iter include/linux/fs.h:1872 [inline]
  new_sync_write+0x4d3/0x770 fs/read_write.c:483
  __vfs_write+0xe1/0x110 fs/read_write.c:496
  vfs_write+0x20c/0x580 fs/read_write.c:558
  ksys_write+0x14f/0x290 fs/read_write.c:611
  __do_sys_write fs/read_write.c:623 [inline]
  __se_sys_write fs/read_write.c:620 [inline]
  __x64_sys_write+0x73/0xb0 fs/read_write.c:620
  do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447a69
Code: e8 cc e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f48c9336d88 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00000000006ddc38 RCX: 0000000000447a69
RDX: 0000000000010094 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00000000006ddc30 R08: 00007f48c9337700 R09: 0000000000000000
R10: 00007f48c9337700 R11: 0000000000000246 R12: 00000000006ddc3c
R13: 00007f48c9336d90 R14: 00007f48c93379c0 R15: 00000000006ddc3c
Modules linked in:
---[ end trace 01e405583d741588 ]---
RIP: 0010:sctp_sched_prio_sched+0x96/0x6f0 net/sctp/stream_sched_prio.c:132
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 0d 05 00 00 48 b8 00 00 00 00  
00 fc ff df 4c 8b 73 50 4d 8d 6e 20 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f  
85 f4 04 00 00 4d 8b 7e 20 4d 85 ff 0f 84 f8 00 00
RSP: 0018:ffff88809e4e7448 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff8880a9533b80 RCX: 1ffff11010347201
RDX: 0000000000000004 RSI: ffffffff8696a77e RDI: ffff8880a9533bd0
RBP: ffff88809e4e7488 R08: ffff88808bf8e300 R09: ffff88809e4e7580
R10: ffffed1013c9cee2 R11: 0000000000000003 R12: ffff8880a9533bc0
R13: 0000000000000020 R14: 0000000000000000 R15: ffff8880a4e92380
FS:  00007f48c9337700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000460687 CR3: 000000009db54000 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#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches