netdev - Re: [PATCH v3 2/2] Bluetooth: fix inconsistent lock state in rfcomm_connect

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:   Fri, 30 Jul 2021 15:40:19 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Desmond Cheong Zhi Xi <desmondcheongzx@...il.com>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Matthieu Baerts <matthieu.baerts@...sares.net>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-bluetooth <linux-bluetooth@...r.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        skhan@...uxfoundation.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH v3 2/2] Bluetooth: fix inconsistent lock state in
 rfcomm_connect_ind

Hi Desmond,

>>> Commit fad003b6c8e3d ("Bluetooth: Fix inconsistent lock state with
>>> RFCOMM") fixed a lockdep warning due to sk->sk_lock.slock being
>>> acquired without disabling softirq while the lock is also used in
>>> softirq context. This was done by disabling interrupts before calling
>>> bh_lock_sock in rfcomm_sk_state_change.
>>> 
>>> Later, this was changed in commit e6da0edc24ee ("Bluetooth: Acquire
>>> sk_lock.slock without disabling interrupts") to disable softirqs
>>> only.
>>> 
>>> However, there is another instance of sk->sk_lock.slock being acquired
>>> without disabling softirq in rfcomm_connect_ind. This patch fixes this
>>> by disabling local bh before the call to bh_lock_sock.
>> back in the days, the packet processing was done in a tasklet, but these days it is done in a workqueue. So shouldn’t this be just converted into a lock_sock(). Am I missing something?
> 
> Thanks for the info. I think you're right, I just didn't understand very much when I wrote this patch.
> 
> If I'm understanding correctly, it seems that both the bh_lock_sock in rfcomm_connect_ind, and spin_lock_bh in rfcomm_sk_state_change need to be changed to lock_sock, otherwise they don't provide any synchronization with other functions in RFCOMM that use lock_sock.
> 
> If that sounds correct I can prepare the patch for that.

please do so and re-run the tests. Thanks.

Regards

Marcel