linux-kernel - Re: general protection fault in vsock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 29 Jul 2020 11:40:18 +0200
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     netdev@...r.kernel.org
Cc:     davem@...emloft.net, decui@...rosoft.com, jhansen@...are.com,
        kuba@...nel.org, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzbot+a61bac2fcc1a7c6623fe@...kaller.appspotmail.com,
        stefanha@...hat.com, syzkaller-bugs@...glegroups.com,
        virtualization@...ts.linux-foundation.org
Subject: Re: general protection fault in vsock_poll

On Wed, Jul 29, 2020 at 01:59:05AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 408624af4c89989117bb2c6517bd50b7708a2fcd
> Author: Stefano Garzarella <sgarzare@...hat.com>
> Date:   Tue Dec 10 10:43:06 2019 +0000
> 
>     vsock: use local transport when it is loaded
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17e6489b100000
> start commit:   92ed3019 Linux 5.8-rc7
> git tree:       upstream
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=1416489b100000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1016489b100000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=84f076779e989e69
> dashboard link: https://syzkaller.appspot.com/bug?extid=a61bac2fcc1a7c6623fe
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15930b64900000
> 
> Reported-by: syzbot+a61bac2fcc1a7c6623fe@...kaller.appspotmail.com
> Fixes: 408624af4c89 ("vsock: use local transport when it is loaded")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 

I'll take a look.

At first glance it seems strange, because if sk_state is TCP_ESTABLISHED,
the transport shouldn't be NULL, that's why we didn't put the check.

Stefano