linux-kernel - Re: [syzbot] WARNING in rtl92cu_hw

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:   Thu, 2 Dec 2021 18:46:54 -0600
From:   Larry Finger <Larry.Finger@...inger.net>
To:     syzbot <syzbot+cce1ee31614c171f5595@...kaller.appspotmail.com>,
        davem@...emloft.net, kuba@...nel.org, kvalo@...eaurora.org,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        pkshih@...ltek.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] WARNING in rtl92cu_hw_init

On 12/2/21 17:47, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    c4bc515d73b5 usb: dwc2: gadget: use existing helper
> git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> console output: https://syzkaller.appspot.com/x/log.txt?x=12c7d311b00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=1fa54650ce78e6dc
> dashboard link: https://syzkaller.appspot.com/bug?extid=cce1ee31614c171f5595
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+cce1ee31614c171f5595@...kaller.appspotmail.com
> 
> ------------[ cut here ]------------
> raw_local_irq_restore() called with IRQs enabled
> WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10
> Modules linked in:
> CPU: 1 PID: 1206 Comm: dhcpcd Not tainted 5.16.0-rc1-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10
> Code: d3 ff cc cc cc cc cc cc cc cc cc cc cc 80 3d e7 4e dc 02 00 74 01 c3 48 c7 c7 a0 85 27 86 c6 05 d6 4e dc 02 01 e8 fd 13 d3 ff <0f> 0b c3 44 8b 05 75 05 e7 02 55 53 65 48 8b 1c 25 80 6f 02 00 45
> RSP: 0018:ffffc90000f0f6a8 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: 0000000000000200 RCX: 0000000000000000
> RDX: ffff8881100f1c00 RSI: ffffffff812bae78 RDI: fffff520001e1ec7
> RBP: 0000000000000200 R08: 0000000000000000 R09: 0000000000000001
> R10: ffffffff812b4c4e R11: 0000000000000000 R12: ffff88814b2047c0
> R13: 0000000000000000 R14: 0000000000000000 R15: 00000000ffffffff
> FS:  00007f0d4252e740(0000) GS:ffff8881f6900000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fd8c7ba7718 CR3: 0000000117bd2000 CR4: 00000000003506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   <TASK>
>   rtl92cu_hw_init.cold+0x119f/0x34c5 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:1003

I think I understand this warning:

The routine in question is the following comment and code:

         /* As this function can take a very long time (up to 350 ms)
          * and can be called with irqs disabled, reenable the irqs
          * to let the other devices continue being serviced.
          *
          * It is safe doing so since our own interrupts will only be enabled
          * in a subsequent step.
          */
         local_save_flags(flags);
         local_irq_enable();
...
exit:
         local_irq_restore(flags);
         return err;

It seems to me that this would lead to the "raw_local_irq_restore() called with 
IRQs enabled" warning.

A brute-force method would be to insert a "local_irq_disable()" call just before 
the local_irq_restore() call. Would that work? Is there a more elegant solution?

Thanks,

Larry