linux-kernel - Re: [syzbot] [usb?] INFO: task hung in usb_register

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]

Message-ID: <32b49d74-16df-4f8e-9956-c7705a900ee9@rowland.harvard.edu>
Date:   Sat, 20 May 2023 11:06:23 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     syzbot <syzbot+e761775e8f4a28711f19@...kaller.appspotmail.com>
Cc:     andreyknvl@...gle.com, charu@...kmarks.net,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [usb?] INFO: task hung in usb_register_dev

On Fri, May 19, 2023 at 10:24:25PM -0700, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
> 
> commit df05a9b05e466a46725564528b277d0c570d0104
> Author: Alan Stern <stern@...land.harvard.edu>
> Date:   Mon Apr 10 19:38:22 2023 +0000
> 
>     USB: sisusbvga: Add endpoint checks
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1286f641280000
> start commit:   7d2a07b76933 Linux 5.14
> git tree:       upstream
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b04081cf516e2565
> dashboard link: https://syzkaller.appspot.com/bug?extid=e761775e8f4a28711f19
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=133519b1300000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=116ec82e300000
> 
> If the result looks correct, please mark the issue as fixed by replying with:
> 
> #syz fix: USB: sisusbvga: Add endpoint checks
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If that commit does fix this problem, it's entirely by accident.  I 
suspect that instead the commit merely prevents the reproducer from 
entering the buggy pathway, but that pathway still exists.

In fact, I'd guess from reading through the driver that the problem is 
that it does dozens of I/O operations, with 5-second timeouts and 
multiple retries, without checking for errors until the end.  All while 
holding a contested mutex.

However the driver is not maintained much AFAICT, so it's not likely to 
get fixed.  It's probably also not used by more than a few people, if 
any.

Alan Stern