diff mbox series

wifi: wfx: fix memory corruption by limiting max_rates to 4

Message ID 20220915131445.30600-1-lech.perczak@camlingroup.com (mailing list archive)
State Changes Requested
Delegated to: Kalle Valo
Headers show
Series wifi: wfx: fix memory corruption by limiting max_rates to 4 | expand

Commit Message

Lech Perczak Sept. 15, 2022, 1:14 p.m. UTC 
From: Paweł Lenkow <pawel.lenkow@camlingroup.com>

During our testing of WFM200 module over SDIO on i.MX6Q-based platform,
we discovered a memory corruption on the system, tracing back to the wfx
driver. Using kfence, it was possible to trace it back to the root
cause, which is hw->max_rates set to 8 in wfx_init_common,
while the maximum defined by IEEE80211_TX_TABLE_SIZE is 4.

This causes array out-of-bounds writes during updates of the rate table,
as seen below:

BUG: KFENCE: memory corruption in kfree_rcu_work+0x320/0x36c

Corrupted memory at 0xe0a4ffe0 [ 0x03 0x03 0x03 0x03 0x01 0x00 0x00
 0x02 0x02 0x02 0x09 0x00 0x21 0xbb 0xbb 0xbb ] (in kfence-#81):
 kfree_rcu_work+0x320/0x36c
 process_one_work+0x3ec/0x920
 worker_thread+0x60/0x7a4
 kthread+0x174/0x1b4
 ret_from_fork+0x14/0x2c
 0x0

kfence-#81: 0xe0a4ffc0-0xe0a4ffdf, size=32, cache=kmalloc-64

allocated by task 297 on cpu 0 at 631.039555s:
 minstrel_ht_update_rates+0x38/0x2b0 [mac80211]
 rate_control_tx_status+0xb4/0x148 [mac80211]
 ieee80211_tx_status_ext+0x364/0x1030 [mac80211]
 ieee80211_tx_status+0xe0/0x118 [mac80211]
 ieee80211_tasklet_handler+0xb0/0xe0 [mac80211]
 tasklet_action_common.constprop.0+0x11c/0x148
 __do_softirq+0x1a4/0x61c
 irq_exit+0xcc/0x104
 call_with_stack+0x18/0x20
 __irq_svc+0x80/0xb0
 wq_worker_sleeping+0x10/0x100
 wq_worker_sleeping+0x10/0x100
 schedule+0x50/0xe0
 schedule_timeout+0x2e0/0x474
 wait_for_completion+0xdc/0x1ec
 mmc_wait_for_req_done+0xc4/0xf8
 mmc_io_rw_extended+0x3b4/0x4ec
 sdio_io_rw_ext_helper+0x290/0x384
 sdio_memcpy_toio+0x30/0x38
 wfx_sdio_copy_to_io+0x88/0x108 [wfx]
 wfx_data_write+0x88/0x1f0 [wfx]
 bh_work+0x1c8/0xcc0 [wfx]
 process_one_work+0x3ec/0x920
 worker_thread+0x60/0x7a4
 kthread+0x174/0x1b4
 ret_from_fork+0x14/0x2c 0x0

Limit hw->max_rates to not exceed IEEE80211_TX_RATE_TABLE_SIZE (4).

To bring back previous value, the global table size limit needs to be
increased beforehand in mac80211.h, or by limiting the iteration count
in minstrel_ht_update_rates against IEEE80211_TX_RATE_TABLE_SIZE as
well.

Fixes: e16e7f0716a6 ("staging: wfx: instantiate mac80211 data")
Cc: Jérôme Pouiller <jerome.pouiller@silabs.com>
Cc: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/

Signed-off-by: Paweł Lenkow <pawel.lenkow@camlingroup.com>
Signed-off-by: Lech Perczak <lech.perczak@camlingroup.com>
---
 drivers/net/wireless/silabs/wfx/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Jérôme Pouiller Sept. 15, 2022, 1:39 p.m. UTC | #1 
[Add Peter in Cc:]

On Thursday 15 September 2022 15:14:45 CEST Lech Perczak wrote:
> From: Paweł Lenkow <pawel.lenkow@camlingroup.com>
> 
> During our testing of WFM200 module over SDIO on i.MX6Q-based platform,
> we discovered a memory corruption on the system, tracing back to the wfx
> driver. Using kfence, it was possible to trace it back to the root
> cause, which is hw->max_rates set to 8 in wfx_init_common,
> while the maximum defined by IEEE80211_TX_TABLE_SIZE is 4.
> 
> This causes array out-of-bounds writes during updates of the rate table,
> as seen below:
> 
> BUG: KFENCE: memory corruption in kfree_rcu_work+0x320/0x36c
> 
> Corrupted memory at 0xe0a4ffe0 [ 0x03 0x03 0x03 0x03 0x01 0x00 0x00
>  0x02 0x02 0x02 0x09 0x00 0x21 0xbb 0xbb 0xbb ] (in kfence-#81):
>  kfree_rcu_work+0x320/0x36c
>  process_one_work+0x3ec/0x920
>  worker_thread+0x60/0x7a4
>  kthread+0x174/0x1b4
>  ret_from_fork+0x14/0x2c
>  0x0
> 
> kfence-#81: 0xe0a4ffc0-0xe0a4ffdf, size=32, cache=kmalloc-64
> 
> allocated by task 297 on cpu 0 at 631.039555s:
>  minstrel_ht_update_rates+0x38/0x2b0 [mac80211]
>  rate_control_tx_status+0xb4/0x148 [mac80211]
>  ieee80211_tx_status_ext+0x364/0x1030 [mac80211]
>  ieee80211_tx_status+0xe0/0x118 [mac80211]
>  ieee80211_tasklet_handler+0xb0/0xe0 [mac80211]
>  tasklet_action_common.constprop.0+0x11c/0x148
>  __do_softirq+0x1a4/0x61c
>  irq_exit+0xcc/0x104
>  call_with_stack+0x18/0x20
>  __irq_svc+0x80/0xb0
>  wq_worker_sleeping+0x10/0x100
>  wq_worker_sleeping+0x10/0x100
>  schedule+0x50/0xe0
>  schedule_timeout+0x2e0/0x474
>  wait_for_completion+0xdc/0x1ec
>  mmc_wait_for_req_done+0xc4/0xf8
>  mmc_io_rw_extended+0x3b4/0x4ec
>  sdio_io_rw_ext_helper+0x290/0x384
>  sdio_memcpy_toio+0x30/0x38
>  wfx_sdio_copy_to_io+0x88/0x108 [wfx]
>  wfx_data_write+0x88/0x1f0 [wfx]
>  bh_work+0x1c8/0xcc0 [wfx]
>  process_one_work+0x3ec/0x920
>  worker_thread+0x60/0x7a4
>  kthread+0x174/0x1b4
>  ret_from_fork+0x14/0x2c 0x0
> 
> Limit hw->max_rates to not exceed IEEE80211_TX_RATE_TABLE_SIZE (4).
> 
> To bring back previous value, the global table size limit needs to be
> increased beforehand in mac80211.h, or by limiting the iteration count
> in minstrel_ht_update_rates against IEEE80211_TX_RATE_TABLE_SIZE as
> well.
> 
> Fixes: e16e7f0716a6 ("staging: wfx: instantiate mac80211 data")

I think the issue has been introduced by ee0e16ab756a ("mac80211:
minstrel_ht: fill all requested rates").


> Cc: Jérôme Pouiller <jerome.pouiller@silabs.com>
> Cc: Kalle Valo <kvalo@kernel.org>
> Link: https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$
> 
> Signed-off-by: Paweł Lenkow <pawel.lenkow@camlingroup.com>
> Signed-off-by: Lech Perczak <lech.perczak@camlingroup.com>
> ---
>  drivers/net/wireless/silabs/wfx/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> index 84d82ddded56..7463fe4b5cae 100644
> --- a/drivers/net/wireless/silabs/wfx/main.c
> +++ b/drivers/net/wireless/silabs/wfx/main.c
> @@ -273,7 +273,7 @@ struct wfx_dev *wfx_init_common(struct device *dev, const struct wfx_platform_da
>         hw->vif_data_size = sizeof(struct wfx_vif);
>         hw->sta_data_size = sizeof(struct wfx_sta_priv);
>         hw->queues = 4;
> -       hw->max_rates = 8;
> +       hw->max_rates = 4;
>         hw->max_rate_tries = 8;
>         hw->extra_tx_headroom = sizeof(struct wfx_hif_msg) + sizeof(struct wfx_hif_req_tx) +
>                                 4 /* alignment */ + 8 /* TKIP IV */;

Do you think the fix should rather be:

------8<----------8<--------
--- i/net/mac80211/rc80211_minstrel_ht.c
+++ w/net/mac80211/rc80211_minstrel_ht.c
@@ -1559,7 +1559,7 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
        minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);

        /* Fill up remaining, keep one entry for max_probe_rate */
-       for (; i < (mp->hw->max_rates - 1); i++)
+       for (; i < min(mp->hw->max_rates, IEEE80211_TX_RATE_TABLE_SIZE) - 1; i++)
                minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);

        if (i < mp->hw->max_rates)
------8<----------8<--------
Lech Perczak Sept. 15, 2022, 2:02 p.m. UTC | #2 
Hi Jérôme,

Answers inline.
[Add Krzysztof in Cc:]

W dniu 15.09.2022 o 15:39, Jérôme Pouiller pisze:
> [Add Peter in Cc:]
>
> On Thursday 15 September 2022 15:14:45 CEST Lech Perczak wrote:
> > From: Paweł Lenkow <pawel.lenkow@camlingroup.com>
> >
> > During our testing of WFM200 module over SDIO on i.MX6Q-based platform,
> > we discovered a memory corruption on the system, tracing back to the wfx
> > driver. Using kfence, it was possible to trace it back to the root
> > cause, which is hw->max_rates set to 8 in wfx_init_common,
> > while the maximum defined by IEEE80211_TX_TABLE_SIZE is 4.
> >
> > This causes array out-of-bounds writes during updates of the rate table,
> > as seen below:
> >
> > BUG: KFENCE: memory corruption in kfree_rcu_work+0x320/0x36c
> >
> > Corrupted memory at 0xe0a4ffe0 [ 0x03 0x03 0x03 0x03 0x01 0x00 0x00
> > 0x02 0x02 0x02 0x09 0x00 0x21 0xbb 0xbb 0xbb ] (in kfence-#81):
> > kfree_rcu_work+0x320/0x36c
> > process_one_work+0x3ec/0x920
> > worker_thread+0x60/0x7a4
> > kthread+0x174/0x1b4
> > ret_from_fork+0x14/0x2c
> > 0x0
> >
> > kfence-#81: 0xe0a4ffc0-0xe0a4ffdf, size=32, cache=kmalloc-64
> >
> > allocated by task 297 on cpu 0 at 631.039555s:
> > minstrel_ht_update_rates+0x38/0x2b0 [mac80211]
> > rate_control_tx_status+0xb4/0x148 [mac80211]
> > ieee80211_tx_status_ext+0x364/0x1030 [mac80211]
> > ieee80211_tx_status+0xe0/0x118 [mac80211]
> > ieee80211_tasklet_handler+0xb0/0xe0 [mac80211]
> > tasklet_action_common.constprop.0+0x11c/0x148
> > __do_softirq+0x1a4/0x61c
> > irq_exit+0xcc/0x104
> > call_with_stack+0x18/0x20
> > __irq_svc+0x80/0xb0
> > wq_worker_sleeping+0x10/0x100
> > wq_worker_sleeping+0x10/0x100
> > schedule+0x50/0xe0
> > schedule_timeout+0x2e0/0x474
> > wait_for_completion+0xdc/0x1ec
> > mmc_wait_for_req_done+0xc4/0xf8
> > mmc_io_rw_extended+0x3b4/0x4ec
> > sdio_io_rw_ext_helper+0x290/0x384
> > sdio_memcpy_toio+0x30/0x38
> > wfx_sdio_copy_to_io+0x88/0x108 [wfx]
> > wfx_data_write+0x88/0x1f0 [wfx]
> > bh_work+0x1c8/0xcc0 [wfx]
> > process_one_work+0x3ec/0x920
> > worker_thread+0x60/0x7a4
> > kthread+0x174/0x1b4
> > ret_from_fork+0x14/0x2c 0x0
> >
> > Limit hw->max_rates to not exceed IEEE80211_TX_RATE_TABLE_SIZE (4).
> >
> > To bring back previous value, the global table size limit needs to be
> > increased beforehand in mac80211.h, or by limiting the iteration count
> > in minstrel_ht_update_rates against IEEE80211_TX_RATE_TABLE_SIZE as
> > well.
> >
> > Fixes: e16e7f0716a6 ("staging: wfx: instantiate mac80211 data")
>
> I think the issue has been introduced by ee0e16ab756a ("mac80211:
> minstrel_ht: fill all requested rates").
>
>
> > Cc: Jérôme Pouiller <jerome.pouiller@silabs.com>
> > Cc: Kalle Valo <kvalo@kernel.org>
> > Link: https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$ <https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$>
> >
> > Signed-off-by: Paweł Lenkow <pawel.lenkow@camlingroup.com>
> > Signed-off-by: Lech Perczak <lech.perczak@camlingroup.com>
> > ---
> > drivers/net/wireless/silabs/wfx/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> > index 84d82ddded56..7463fe4b5cae 100644
> > --- a/drivers/net/wireless/silabs/wfx/main.c
> > +++ b/drivers/net/wireless/silabs/wfx/main.c
> > @@ -273,7 +273,7 @@ struct wfx_dev *wfx_init_common(struct device *dev, const struct wfx_platform_da
> > hw->vif_data_size = sizeof(struct wfx_vif);
> > hw->sta_data_size = sizeof(struct wfx_sta_priv);
> > hw->queues = 4;
> > - hw->max_rates = 8;
> > + hw->max_rates = 4;
> > hw->max_rate_tries = 8;
> > hw->extra_tx_headroom = sizeof(struct wfx_hif_msg) + sizeof(struct wfx_hif_req_tx) +
> > 4 /* alignment */ + 8 /* TKIP IV */;
>
> Do you think the fix should rather be:
>
> ------8<----------8<--------
> --- i/net/mac80211/rc80211_minstrel_ht.c
> +++ w/net/mac80211/rc80211_minstrel_ht.c
> @@ -1559,7 +1559,7 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
> minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);
>
> /* Fill up remaining, keep one entry for max_probe_rate */
> - for (; i < (mp->hw->max_rates - 1); i++)
> + for (; i < min(mp->hw->max_rates, IEEE80211_TX_RATE_TABLE_SIZE) - 1; i++)
> minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);
>
> if (i < mp->hw->max_rates)
> ------8<----------8<--------
>
We thought about this as well - or about adding assertion to the function which does the memory allocation,
but there are more 4-element arrays in mac80211, handled under different defines, which can be confusing.

carl9170 driver has BUILD_BUG_ON to guard from that precisely - see:
https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/carl9170/tx.c#L879
I think, that the second BUILD_BUG_ON could be moved to mac80211 core, so that it is checked always,
not only when CARL9170 is enabled.

I think both changes should be applied - or, alternatively, in minstrel_ht_set_rate, we could use:
BUG_ON(mp->hw->max_rates > IEEE80211_TX_RATE_TABLE_SIZE);
to quickly catch misbehaving drivers in future.

Since this concerns mac80211 core, let's add Johannes to the loop as well.
>
>
> -- 
> Jérôme Pouiller
>
>
Peter Seiderer Sept. 15, 2022, 6:21 p.m. UTC | #3 
Hello *,

On Thu, 15 Sep 2022 16:02:34 +0200, Lech Perczak <lech.perczak@camlingroup.com> wrote:

> Hi Jérôme,
> 
> Answers inline.
> [Add Krzysztof in Cc:]
> 
> W dniu 15.09.2022 o 15:39, Jérôme Pouiller pisze:
> > [Add Peter in Cc:]
> >
> > On Thursday 15 September 2022 15:14:45 CEST Lech Perczak wrote:  
> > > From: Paweł Lenkow <pawel.lenkow@camlingroup.com>
> > >
> > > During our testing of WFM200 module over SDIO on i.MX6Q-based platform,
> > > we discovered a memory corruption on the system, tracing back to the wfx
> > > driver. Using kfence, it was possible to trace it back to the root
> > > cause, which is hw->max_rates set to 8 in wfx_init_common,
> > > while the maximum defined by IEEE80211_TX_TABLE_SIZE is 4.
> > >
> > > This causes array out-of-bounds writes during updates of the rate table,
> > > as seen below:
> > >
> > > BUG: KFENCE: memory corruption in kfree_rcu_work+0x320/0x36c
> > >
> > > Corrupted memory at 0xe0a4ffe0 [ 0x03 0x03 0x03 0x03 0x01 0x00 0x00
> > > 0x02 0x02 0x02 0x09 0x00 0x21 0xbb 0xbb 0xbb ] (in kfence-#81):
> > > kfree_rcu_work+0x320/0x36c
> > > process_one_work+0x3ec/0x920
> > > worker_thread+0x60/0x7a4
> > > kthread+0x174/0x1b4
> > > ret_from_fork+0x14/0x2c
> > > 0x0
> > >
> > > kfence-#81: 0xe0a4ffc0-0xe0a4ffdf, size=32, cache=kmalloc-64
> > >
> > > allocated by task 297 on cpu 0 at 631.039555s:
> > > minstrel_ht_update_rates+0x38/0x2b0 [mac80211]
> > > rate_control_tx_status+0xb4/0x148 [mac80211]
> > > ieee80211_tx_status_ext+0x364/0x1030 [mac80211]
> > > ieee80211_tx_status+0xe0/0x118 [mac80211]
> > > ieee80211_tasklet_handler+0xb0/0xe0 [mac80211]
> > > tasklet_action_common.constprop.0+0x11c/0x148
> > > __do_softirq+0x1a4/0x61c
> > > irq_exit+0xcc/0x104
> > > call_with_stack+0x18/0x20
> > > __irq_svc+0x80/0xb0
> > > wq_worker_sleeping+0x10/0x100
> > > wq_worker_sleeping+0x10/0x100
> > > schedule+0x50/0xe0
> > > schedule_timeout+0x2e0/0x474
> > > wait_for_completion+0xdc/0x1ec
> > > mmc_wait_for_req_done+0xc4/0xf8
> > > mmc_io_rw_extended+0x3b4/0x4ec
> > > sdio_io_rw_ext_helper+0x290/0x384
> > > sdio_memcpy_toio+0x30/0x38
> > > wfx_sdio_copy_to_io+0x88/0x108 [wfx]
> > > wfx_data_write+0x88/0x1f0 [wfx]
> > > bh_work+0x1c8/0xcc0 [wfx]
> > > process_one_work+0x3ec/0x920
> > > worker_thread+0x60/0x7a4
> > > kthread+0x174/0x1b4
> > > ret_from_fork+0x14/0x2c 0x0
> > >
> > > Limit hw->max_rates to not exceed IEEE80211_TX_RATE_TABLE_SIZE (4).
> > >
> > > To bring back previous value, the global table size limit needs to be
> > > increased beforehand in mac80211.h, or by limiting the iteration count
> > > in minstrel_ht_update_rates against IEEE80211_TX_RATE_TABLE_SIZE as
> > > well.
> > >
> > > Fixes: e16e7f0716a6 ("staging: wfx: instantiate mac80211 data")  
> >
> > I think the issue has been introduced by ee0e16ab756a ("mac80211:
> > minstrel_ht: fill all requested rates").

Ups, sorry for creating a regression (and many thanks for investigation)...

> >
> >  
> > > Cc: Jérôme Pouiller <jerome.pouiller@silabs.com>
> > > Cc: Kalle Valo <kvalo@kernel.org>
> > > Link: https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$ <https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$>
> > >
> > > Signed-off-by: Paweł Lenkow <pawel.lenkow@camlingroup.com>
> > > Signed-off-by: Lech Perczak <lech.perczak@camlingroup.com>
> > > ---
> > > drivers/net/wireless/silabs/wfx/main.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> > > index 84d82ddded56..7463fe4b5cae 100644
> > > --- a/drivers/net/wireless/silabs/wfx/main.c
> > > +++ b/drivers/net/wireless/silabs/wfx/main.c
> > > @@ -273,7 +273,7 @@ struct wfx_dev *wfx_init_common(struct device *dev, const struct wfx_platform_da
> > > hw->vif_data_size = sizeof(struct wfx_vif);
> > > hw->sta_data_size = sizeof(struct wfx_sta_priv);
> > > hw->queues = 4;
> > > - hw->max_rates = 8;
> > > + hw->max_rates = 4;

Quick grep for max_rates did show the same for:

drivers/net/wireless/st/cw1200/main.c:  hw->max_rates = 8;

> > > hw->max_rate_tries = 8;
> > > hw->extra_tx_headroom = sizeof(struct wfx_hif_msg) + sizeof(struct wfx_hif_req_tx) +
> > > 4 /* alignment */ + 8 /* TKIP IV */;  
> >

Think the following suggested fix is the right way to go (and keep hw->max_rates
value according to the hardware capabilities(?) of the wifi device)...

> > Do you think the fix should rather be:
> >
> > ------8<----------8<--------
> > --- i/net/mac80211/rc80211_minstrel_ht.c
> > +++ w/net/mac80211/rc80211_minstrel_ht.c
> > @@ -1559,7 +1559,7 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
> > minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);
> >
> > /* Fill up remaining, keep one entry for max_probe_rate */
> > - for (; i < (mp->hw->max_rates - 1); i++)
> > + for (; i < min(mp->hw->max_rates, IEEE80211_TX_RATE_TABLE_SIZE) - 1; i++)
> > minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);
> >

Same change needed here:

> > if (i < mp->hw->max_rates)

    if (i < min(mp->hw->max_rates, IEEE80211_TX_RATE_TABLE_SIZE))

> > ------8<----------8<--------
> >  
> We thought about this as well - or about adding assertion to the function which does the memory allocation,
> but there are more 4-element arrays in mac80211, handled under different defines, which can be confusing.
> 
> carl9170 driver has BUILD_BUG_ON to guard from that precisely - see:
> https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/carl9170/tx.c#L879
> I think, that the second BUILD_BUG_ON could be moved to mac80211 core, so that it is checked always,
> not only when CARL9170 is enabled.
> 
> I think both changes should be applied - or, alternatively, in minstrel_ht_set_rate, we could use:
> BUG_ON(mp->hw->max_rates > IEEE80211_TX_RATE_TABLE_SIZE);
> to quickly catch misbehaving drivers in future.

Think with the suggested changes to minstrel_ht_set_rate no further assertion
is needed...

Regards,
Peter

> 
> Since this concerns mac80211 core, let's add Johannes to the loop as well.
> >
> >
> > -- 
> > Jérôme Pouiller
> >
> >
Pawel Lenkow Sept. 19, 2022, 3:17 p.m. UTC | #4 
Hi!

Thank you for your suggestions and comments. 

We have submitted new patch here:

https://patchwork.kernel.org/project/linux-wireless/patch/20220919150135.90785-1-lech.perczak@camlingroup.com/


On 15.09.2022 20:21, Peter Seiderer wrote:
> Hello *,
> 
> On Thu, 15 Sep 2022 16:02:34 +0200, Lech Perczak <lech.perczak@camlingroup.com> wrote:
> 
>> Hi Jérôme,
>>
>> Answers inline.
>> [Add Krzysztof in Cc:]
>>
>> W dniu 15.09.2022 o 15:39, Jérôme Pouiller pisze:
>>> [Add Peter in Cc:]
>>>
>>> On Thursday 15 September 2022 15:14:45 CEST Lech Perczak wrote:
>>>> From: Paweł Lenkow <pawel.lenkow@camlingroup.com>
>>>>
>>>> During our testing of WFM200 module over SDIO on i.MX6Q-based platform,
>>>> we discovered a memory corruption on the system, tracing back to the wfx
>>>> driver. Using kfence, it was possible to trace it back to the root
>>>> cause, which is hw->max_rates set to 8 in wfx_init_common,
>>>> while the maximum defined by IEEE80211_TX_TABLE_SIZE is 4.
>>>>
>>>> This causes array out-of-bounds writes during updates of the rate table,
>>>> as seen below:
>>>>
>>>> BUG: KFENCE: memory corruption in kfree_rcu_work+0x320/0x36c
>>>>
>>>> Corrupted memory at 0xe0a4ffe0 [ 0x03 0x03 0x03 0x03 0x01 0x00 0x00
>>>> 0x02 0x02 0x02 0x09 0x00 0x21 0xbb 0xbb 0xbb ] (in kfence-#81):
>>>> kfree_rcu_work+0x320/0x36c
>>>> process_one_work+0x3ec/0x920
>>>> worker_thread+0x60/0x7a4
>>>> kthread+0x174/0x1b4
>>>> ret_from_fork+0x14/0x2c
>>>> 0x0
>>>>
>>>> kfence-#81: 0xe0a4ffc0-0xe0a4ffdf, size=32, cache=kmalloc-64
>>>>
>>>> allocated by task 297 on cpu 0 at 631.039555s:
>>>> minstrel_ht_update_rates+0x38/0x2b0 [mac80211]
>>>> rate_control_tx_status+0xb4/0x148 [mac80211]
>>>> ieee80211_tx_status_ext+0x364/0x1030 [mac80211]
>>>> ieee80211_tx_status+0xe0/0x118 [mac80211]
>>>> ieee80211_tasklet_handler+0xb0/0xe0 [mac80211]
>>>> tasklet_action_common.constprop.0+0x11c/0x148
>>>> __do_softirq+0x1a4/0x61c
>>>> irq_exit+0xcc/0x104
>>>> call_with_stack+0x18/0x20
>>>> __irq_svc+0x80/0xb0
>>>> wq_worker_sleeping+0x10/0x100
>>>> wq_worker_sleeping+0x10/0x100
>>>> schedule+0x50/0xe0
>>>> schedule_timeout+0x2e0/0x474
>>>> wait_for_completion+0xdc/0x1ec
>>>> mmc_wait_for_req_done+0xc4/0xf8
>>>> mmc_io_rw_extended+0x3b4/0x4ec
>>>> sdio_io_rw_ext_helper+0x290/0x384
>>>> sdio_memcpy_toio+0x30/0x38
>>>> wfx_sdio_copy_to_io+0x88/0x108 [wfx]
>>>> wfx_data_write+0x88/0x1f0 [wfx]
>>>> bh_work+0x1c8/0xcc0 [wfx]
>>>> process_one_work+0x3ec/0x920
>>>> worker_thread+0x60/0x7a4
>>>> kthread+0x174/0x1b4
>>>> ret_from_fork+0x14/0x2c 0x0
>>>>
>>>> Limit hw->max_rates to not exceed IEEE80211_TX_RATE_TABLE_SIZE (4).
>>>>
>>>> To bring back previous value, the global table size limit needs to be
>>>> increased beforehand in mac80211.h, or by limiting the iteration count
>>>> in minstrel_ht_update_rates against IEEE80211_TX_RATE_TABLE_SIZE as
>>>> well.
>>>>
>>>> Fixes: e16e7f0716a6 ("staging: wfx: instantiate mac80211 data")
>>>
>>> I think the issue has been introduced by ee0e16ab756a ("mac80211:
>>> minstrel_ht: fill all requested rates").
> 
> Ups, sorry for creating a regression (and many thanks for investigation)...
> 
>>>
>>>
>>>> Cc: Jérôme Pouiller <jerome.pouiller@silabs.com>
>>>> Cc: Kalle Valo <kvalo@kernel.org>
>>>> Link: https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$<https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$> <https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$<https://urldefense.com/v3/__https://lore.kernel.org/all/12e5adcd-8aed-f0f7-70cc-4fb7b656b829@camlingroup.com/__;!!N30Cs7Jr!ReVaYMRjWoJzG95KRgrZTGAw0bmt5lnLLpRkt574SRvIoKLD2xl53YKUiLpN4PfXpjSLIQ9KvgVy9Wi4jeJE8axP9M4Odgk$>>
>>>>
>>>> Signed-off-by: Paweł Lenkow <pawel.lenkow@camlingroup.com>
>>>> Signed-off-by: Lech Perczak <lech.perczak@camlingroup.com>
>>>> ---
>>>> drivers/net/wireless/silabs/wfx/main.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
>>>> index 84d82ddded56..7463fe4b5cae 100644
>>>> --- a/drivers/net/wireless/silabs/wfx/main.c
>>>> +++ b/drivers/net/wireless/silabs/wfx/main.c
>>>> @@ -273,7 +273,7 @@ struct wfx_dev *wfx_init_common(struct device *dev, const struct wfx_platform_da
>>>> hw->vif_data_size = sizeof(struct wfx_vif);
>>>> hw->sta_data_size = sizeof(struct wfx_sta_priv);
>>>> hw->queues = 4;
>>>> - hw->max_rates = 8;
>>>> + hw->max_rates = 4;
> 
> Quick grep for max_rates did show the same for:
> 
> drivers/net/wireless/st/cw1200/main.c: hw->max_rates = 8;
> 
>>>> hw->max_rate_tries = 8;
>>>> hw->extra_tx_headroom = sizeof(struct wfx_hif_msg) + sizeof(struct wfx_hif_req_tx) +
>>>> 4 /* alignment */ + 8 /* TKIP IV */;
>>>
> 
> Think the following suggested fix is the right way to go (and keep hw->max_rates
> value according to the hardware capabilities(?) of the wifi device)...
> 
>>> Do you think the fix should rather be:
>>>
>>> ------8<----------8<--------
>>> --- i/net/mac80211/rc80211_minstrel_ht.c
>>> +++ w/net/mac80211/rc80211_minstrel_ht.c
>>> @@ -1559,7 +1559,7 @@ minstrel_ht_update_rates(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
>>> minstrel_ht_set_rate(mp, mi, rates, i++, mi->max_tp_rate[0]);
>>>
>>> /* Fill up remaining, keep one entry for max_probe_rate */
>>> - for (; i < (mp->hw->max_rates - 1); i++)
>>> + for (; i < min(mp->hw->max_rates, IEEE80211_TX_RATE_TABLE_SIZE) - 1; i++)
>>> minstrel_ht_set_rate(mp, mi, rates, i, mi->max_tp_rate[i]);
>>>
> 
> Same change needed here:
> 
>>> if (i < mp->hw->max_rates)
> 
> if (i < min(mp->hw->max_rates, IEEE80211_TX_RATE_TABLE_SIZE))
> 
>>> ------8<----------8<--------
>>>
>> We thought about this as well - or about adding assertion to the function which does the memory allocation,
>> but there are more 4-element arrays in mac80211, handled under different defines, which can be confusing.
>>
>> carl9170 driver has BUILD_BUG_ON to guard from that precisely - see:
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/carl9170/tx.c#L879<https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/carl9170/tx.c#L879>
>> I think, that the second BUILD_BUG_ON could be moved to mac80211 core, so that it is checked always,
>> not only when CARL9170 is enabled.
>>
>> I think both changes should be applied - or, alternatively, in minstrel_ht_set_rate, we could use:
>> BUG_ON(mp->hw->max_rates > IEEE80211_TX_RATE_TABLE_SIZE);
>> to quickly catch misbehaving drivers in future.
> 
> Think with the suggested changes to minstrel_ht_set_rate no further assertion
> is needed...
> 
> Regards,
> Peter
> 
>>
>> Since this concerns mac80211 core, let's add Johannes to the loop as well.
>>>
>>>
>>> --
>>> Jérôme Pouiller
>>>
>>>
> ___
> This email originated from outside of Camlin Group. Do not click on links or open attachments unless you are confident they are secure. If in doubt, please raise a security incident via the following portal: Camlin Helpdesk – Report an Information Security Incident/Non-Conformance <https://camlin-helpdesk.atlassian.net/servicedesk/customer/portal/2/group/34/create/62>
>
diff mbox series

Patch

diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
index 84d82ddded56..7463fe4b5cae 100644
--- a/drivers/net/wireless/silabs/wfx/main.c
+++ b/drivers/net/wireless/silabs/wfx/main.c
@@ -273,7 +273,7 @@  struct wfx_dev *wfx_init_common(struct device *dev, const struct wfx_platform_da
 	hw->vif_data_size = sizeof(struct wfx_vif);
 	hw->sta_data_size = sizeof(struct wfx_sta_priv);
 	hw->queues = 4;
-	hw->max_rates = 8;
+	hw->max_rates = 4;
 	hw->max_rate_tries = 8;
 	hw->extra_tx_headroom = sizeof(struct wfx_hif_msg) + sizeof(struct wfx_hif_req_tx) +
 				4 /* alignment */ + 8 /* TKIP IV */;