netdev - Re: [PATCH] mac80211: fix race in ieee80211_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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ftdgokao.fsf@tynnyri.adurom.net>
Date:   Mon, 06 Apr 2020 15:44:47 +0300
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     linux-wireless@...r.kernel.org, johannes@...solutions.net,
        davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, matthias.schoepfer@...inx.io,
        Philipp.Berg@...bherr.com, Michael.Weitner@...bherr.com,
        daniel.thompson@...aro.org, loic.poulain@...aro.org,
        stable@...r.kernel.org
Subject: Re: [PATCH] mac80211: fix race in ieee80211_register_hw()

Sumit Garg <sumit.garg@...aro.org> writes:

> A race condition leading to a kernel crash is observed during invocation
> of ieee80211_register_hw() on a dragonboard410c device having wcn36xx
> driver built as a loadable module along with a wifi manager in user-space
> waiting for a wifi device (wlanX) to be active.
>
> Sequence diagram for a particular kernel crash scenario:
>
>     user-space  ieee80211_register_hw()  RX IRQ
>     +++++++++++++++++++++++++++++++++++++++++++++
>        |                    |             |
>        |<---wlan0---wiphy_register()      |
>        |----start wlan0---->|             |
>        |                    |<---IRQ---(RX packet)
>        |              Kernel crash        |
>        |              due to unallocated  |
>        |              workqueue.          |
>        |                    |             |
>        |       alloc_ordered_workqueue()  |
>        |                    |             |
>        |              Misc wiphy init.    |
>        |                    |             |
>        |            ieee80211_if_add()    |
>        |                    |             |
>
> As evident from above sequence diagram, this race condition isn't specific
> to a particular wifi driver but rather the initialization sequence in
> ieee80211_register_hw() needs to be fixed. So re-order the initialization
> sequence and the updated sequence diagram would look like:
>
>     user-space  ieee80211_register_hw()  RX IRQ
>     +++++++++++++++++++++++++++++++++++++++++++++
>        |                    |             |
>        |       alloc_ordered_workqueue()  |
>        |                    |             |
>        |              Misc wiphy init.    |
>        |                    |             |
>        |<---wlan0---wiphy_register()      |
>        |----start wlan0---->|             |
>        |                    |<---IRQ---(RX packet)
>        |                    |             |
>        |            ieee80211_if_add()    |
>        |                    |             |
>
> Cc: <stable@...r.kernel.org>
> Signed-off-by: Sumit Garg <sumit.garg@...aro.org>

I have understood that no frames should be received until mac80211 calls
struct ieee80211_ops::start:

 * @start: Called before the first netdevice attached to the hardware
 *         is enabled. This should turn on the hardware and must turn on
 *         frame reception (for possibly enabled monitor interfaces.)
   
So I would claim that this is a bug in wcn36xx.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches