[PATCH] b43: Fix possible a data race in b43_op_tx()

[PATCH] b43: Fix possible a data race in b43_op_tx()

[Jia-Ju Bai]

The functions b43_op_tx() and b43_tx_work() may be concurrently executed.

In b43_tx_work(), the variable wl->tx_queue_stopped[queue_num] is
accessed with holding a mutex lock wl->mutex. But in b43_op_tx(), the
identical variable wl->tx_queue_stopped[skb->queue_mapping] is accessed
without holding this mutex lock. Thus, a possible data race may occur.

To fix this data race, in b43_op_tx(), the variable 
wl->tx_queue_stopped[skb->queue_mapping] is accessed with holding the 
mutex lock wl->mutex.

This data race is found by the runtime testing of our tool DILP-2.

Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
 drivers/net/wireless/broadcom/b43/main.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireless/broadcom/b43/main.c
index 39da1a4c30ac..adedb38f50f2 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -3625,6 +3625,11 @@ static void b43_op_tx(struct ieee80211_hw *hw,
 		      struct sk_buff *skb)
 {
 	struct b43_wl *wl = hw_to_b43_wl(hw);
+	bool stopped;
+
+	mutex_lock(&wl->mutex);
+	stopped = wl->tx_queue_stopped[skb->queue_mapping];
+	mutex_unlock(&wl->mutex);
 
 	if (unlikely(skb->len < 2 + 2 + 6)) {
 		/* Too short, this can't be a valid frame. */
@@ -3634,7 +3639,7 @@ static void b43_op_tx(struct ieee80211_hw *hw,
 	B43_WARN_ON(skb_shinfo(skb)->nr_frags);
 
 	skb_queue_tail(&wl->tx_queue[skb->queue_mapping], skb);
-	if (!wl->tx_queue_stopped[skb->queue_mapping]) {
+	if (!stopped) {
 		ieee80211_queue_work(wl->hw, &wl->tx_work);
 	} else {
 		ieee80211_stop_queue(wl->hw, skb->queue_mapping);
-- 
2.17.1

Re: [PATCH] b43: Fix possible a data race in b43_op_tx()

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

On Sun, 12 Jan 2020 00:14:55 +0800
Jia-Ju Bai <baijiaju1990@gmail.com> wrote:

> The functions b43_op_tx() and b43_tx_work() may be concurrently executed.
> 
> In b43_tx_work(), the variable wl->tx_queue_stopped[queue_num] is
> accessed with holding a mutex lock wl->mutex. But in b43_op_tx(), the
> identical variable wl->tx_queue_stopped[skb->queue_mapping] is accessed
> without holding this mutex lock. Thus, a possible data race may occur.
> 
> To fix this data race, in b43_op_tx(), the variable 
> wl->tx_queue_stopped[skb->queue_mapping] is accessed with holding the 
> mutex lock wl->mutex.
> 
> This data race is found by the runtime testing of our tool DILP-2.
> 
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
>  drivers/net/wireless/broadcom/b43/main.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireless/broadcom/b43/main.c
> index 39da1a4c30ac..adedb38f50f2 100644
> --- a/drivers/net/wireless/broadcom/b43/main.c
> +++ b/drivers/net/wireless/broadcom/b43/main.c
> @@ -3625,6 +3625,11 @@ static void b43_op_tx(struct ieee80211_hw *hw,
>  		      struct sk_buff *skb)
>  {
>  	struct b43_wl *wl = hw_to_b43_wl(hw);
> +	bool stopped;
> +
> +	mutex_lock(&wl->mutex);
> +	stopped = wl->tx_queue_stopped[skb->queue_mapping];
> +	mutex_unlock(&wl->mutex);
>  
>  	if (unlikely(skb->len < 2 + 2 + 6)) {
>  		/* Too short, this can't be a valid frame. */
> @@ -3634,7 +3639,7 @@ static void b43_op_tx(struct ieee80211_hw *hw,
>  	B43_WARN_ON(skb_shinfo(skb)->nr_frags);
>  
>  	skb_queue_tail(&wl->tx_queue[skb->queue_mapping], skb);
> -	if (!wl->tx_queue_stopped[skb->queue_mapping]) {
> +	if (!stopped) {
>  		ieee80211_queue_work(wl->hw, &wl->tx_work);
>  	} else {
>  		ieee80211_stop_queue(wl->hw, skb->queue_mapping);

Hi,

thanks for your patch.

Unfortunately it is not possible to acquire a sleeping mutex in the tx
op:

/**
 * struct ieee80211_ops - callbacks from mac80211 to the driver
 *
 * @tx: Handler that 802.11 module calls for each transmitted frame.
 *      skb contains the buffer starting from the IEEE 802.11 header.
 *      The low-level driver should send the frame out based on
 *      configuration in the TX control data. This handler should,
 *      preferably, never fail and stop queues appropriately.
 *      Must be atomic.
        ^^^^^^^^^^^^^^

I also don't think that the change really fixes any race.
The variable tx_queue_stopped is a boolean. Reading that under mutex
and then doing the actual action based on a copy does not really change
anything. The other end may just set it to false after mutex_unlock,
but before the queue_work. Thus this change does probably even increase
the race window size.

The other thing to consider is:
What can actually go wrong, if the race happens?
I currently don't see any fatal behavior.
A packet might still make it into the queue, although it has already
been stopped. But that's not fatal.

-- 
Michael

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]