[PATCH] ath10k: fix recent bandwidth conversion bug

[PATCH] ath10k: fix recent bandwidth conversion bug

[Christian Lamparter]

The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
the index of RATE_INFO_BW_20, but the updates to ath10k missed
the special bandwidth calculation case in
ath10k_update_per_peer_tx_stats().

Fixes: 842be75c77cb ("cfg80211: make RATE_INFO_BW_20 the default")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a3f5dc78353f..26b0d201a698 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
 
 #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
 
+static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,
+	RATE_INFO_BW_80, RATE_INFO_BW_160 };
+
 static void ath10k_htt_rx_h_rates(struct ath10k *ar,
 				  struct ieee80211_rx_status *status,
 				  struct htt_rx_desc *rxd)
@@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
 		if (sgi)
 			status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
 
-		switch (bw) {
-		/* 20MHZ */
-		case 0:
-			break;
-		/* 40MHZ */
-		case 1:
-			status->bw = RATE_INFO_BW_40;
-			break;
-		/* 80MHZ */
-		case 2:
-			status->bw = RATE_INFO_BW_80;
-			break;
-		case 3:
-			status->bw = RATE_INFO_BW_160;
-			break;
-		}
-
+		status->bw = ath10k_bw_to_mac80211[bw];
 		status->encoding = RX_ENC_VHT;
 		break;
 	default:
@@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
 		arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
 
 	arsta->txrate.nss = txrate.nss;
-	arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+	arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
 }
 
 static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
-- 
2.15.0

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Sebastian Gottschall]

true. good finding.

Am 01.11.2017 um 21:01 schrieb Christian Lamparter:
> The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
> the index of RATE_INFO_BW_20, but the updates to ath10k missed
> the special bandwidth calculation case in
> ath10k_update_per_peer_tx_stats().
>
> Fixes: 842be75c77cb ("cfg80211: make RATE_INFO_BW_20 the default")
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
>   drivers/net/wireless/ath/ath10k/htt_rx.c | 23 +++++------------------
>   1 file changed, 5 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index a3f5dc78353f..26b0d201a698 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
>   
>   #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
>   
> +static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,
> +	RATE_INFO_BW_80, RATE_INFO_BW_160 };
> +
>   static void ath10k_htt_rx_h_rates(struct ath10k *ar,
>   				  struct ieee80211_rx_status *status,
>   				  struct htt_rx_desc *rxd)
> @@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
>   		if (sgi)
>   			status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
>   
> -		switch (bw) {
> -		/* 20MHZ */
> -		case 0:
> -			break;
> -		/* 40MHZ */
> -		case 1:
> -			status->bw = RATE_INFO_BW_40;
> -			break;
> -		/* 80MHZ */
> -		case 2:
> -			status->bw = RATE_INFO_BW_80;
> -			break;
> -		case 3:
> -			status->bw = RATE_INFO_BW_160;
> -			break;
> -		}
> -
> +		status->bw = ath10k_bw_to_mac80211[bw];
>   		status->encoding = RX_ENC_VHT;
>   		break;
>   	default:
> @@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
>   		arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
>   
>   	arsta->txrate.nss = txrate.nss;
> -	arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
> +	arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
>   }
>   
>   static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Sebastian Gottschall]

a additional array bounds check would be good

Am 01.11.2017 um 21:01 schrieb Christian Lamparter:
> The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
> the index of RATE_INFO_BW_20, but the updates to ath10k missed
> the special bandwidth calculation case in
> ath10k_update_per_peer_tx_stats().
>
> Fixes: 842be75c77cb ("cfg80211: make RATE_INFO_BW_20 the default")
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
>   drivers/net/wireless/ath/ath10k/htt_rx.c | 23 +++++------------------
>   1 file changed, 5 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
> index a3f5dc78353f..26b0d201a698 100644
> --- a/drivers/net/wireless/ath/ath10k/htt_rx.c
> +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
> @@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
>   
>   #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
>   
> +static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,
> +	RATE_INFO_BW_80, RATE_INFO_BW_160 };
> +
>   static void ath10k_htt_rx_h_rates(struct ath10k *ar,
>   				  struct ieee80211_rx_status *status,
>   				  struct htt_rx_desc *rxd)
> @@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
>   		if (sgi)
>   			status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
>   
> -		switch (bw) {
> -		/* 20MHZ */
> -		case 0:
> -			break;
> -		/* 40MHZ */
> -		case 1:
> -			status->bw = RATE_INFO_BW_40;
> -			break;
> -		/* 80MHZ */
> -		case 2:
> -			status->bw = RATE_INFO_BW_80;
> -			break;
> -		case 3:
> -			status->bw = RATE_INFO_BW_160;
> -			break;
> -		}
> -
> +		status->bw = ath10k_bw_to_mac80211[bw];
>   		status->encoding = RX_ENC_VHT;
>   		break;
>   	default:
> @@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
>   		arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
>   
>   	arsta->txrate.nss = txrate.nss;
> -	arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
> +	arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
>   }
>   
>   static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Christian Lamparter]

On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:
> a additional array bounds check would be good

Ah, about that:

the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
in the following way [0]:
|	bw = info2 & 3;

the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by [1]:
|	txrate.bw = ATH10K_HW_BW(peer_stats->flags);

ATH10K_HW_BW is a macro defined as [2]:
|	#define ATH10K_HW_BW(flags)		(((flags) >> 3) & 0x3)

In both cases the bandwidth values already are limited to 0-3 by
the "and 3" operation.

[0] <https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/htt_rx.c#L646>

[1] <https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/htt_rx.c#L2254>
[2] <https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/wmi.h#L4810>


> > @@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
> >   
> >   #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
> >   
> > +static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,
> > +	RATE_INFO_BW_80, RATE_INFO_BW_160 };
> > +
> >   static void ath10k_htt_rx_h_rates(struct ath10k *ar,
> >   				  struct ieee80211_rx_status *status,
> >   				  struct htt_rx_desc *rxd)
> > @@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
> >   		if (sgi)
> >   			status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
> >   
> > [...]
> > +		status->bw = ath10k_bw_to_mac80211[bw];
> >   		status->encoding = RX_ENC_VHT;
> >   		break;
> >   	default:
> > @@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
> >   		arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
> >   
> >   	arsta->txrate.nss = txrate.nss;
> > -	arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
> > +	arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
> >   }
> >   
> >   static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Sebastian Gottschall]

i know. saw that later too. code should be safe

Am 02.11.2017 um 20:34 schrieb Christian Lamparter:
> On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:
>> a additional array bounds check would be good
> Ah, about that:
>
> the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
> in the following way [0]:
> |	bw = info2 & 3;
>
> the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by [1]:
> |	txrate.bw = ATH10K_HW_BW(peer_stats->flags);
>
> ATH10K_HW_BW is a macro defined as [2]:
> |	#define ATH10K_HW_BW(flags)		(((flags) >> 3) & 0x3)
>
> In both cases the bandwidth values already are limited to 0-3 by
> the "and 3" operation.
>
> [0] <https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/htt_rx.c#L646>
>
> [1] <https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/htt_rx.c#L2254>
> [2] <https://elixir.free-electrons.com/linux/v4.14-rc7/source/drivers/net/wireless/ath/ath10k/wmi.h#L4810>
>
>
>>> @@ -592,6 +592,9 @@ struct amsdu_subframe_hdr {
>>>    
>>>    #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
>>>    
>>> +static const u8 ath10k_bw_to_mac80211[] = { RATE_INFO_BW_20, RATE_INFO_BW_40,
>>> +	RATE_INFO_BW_80, RATE_INFO_BW_160 };
>>> +
>>>    static void ath10k_htt_rx_h_rates(struct ath10k *ar,
>>>    				  struct ieee80211_rx_status *status,
>>>    				  struct htt_rx_desc *rxd)
>>> @@ -694,23 +697,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
>>>    		if (sgi)
>>>    			status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
>>>    
>>> [...]
>>> +		status->bw = ath10k_bw_to_mac80211[bw];
>>>    		status->encoding = RX_ENC_VHT;
>>>    		break;
>>>    	default:
>>> @@ -2297,7 +2284,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
>>>    		arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
>>>    
>>>    	arsta->txrate.nss = txrate.nss;
>>> -	arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
>>> +	arsta->txrate.bw = ath10k_bw_to_mac80211[txrate.bw];
>>>    }
>>>    
>>>    static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
>
>
>

-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Johannes Berg]

On Thu, 2017-11-02 at 22:08 +0100, Sebastian Gottschall wrote:
> i know. saw that later too. code should be safe

It would be good if you could adhere to our mailing list customs and
start quoting properly, instead of just top-posting.

Thanks,
johannes

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Kalle Valo]

Christian Lamparter <chunkeey@gmail.com> writes:

> On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:
>> a additional array bounds check would be good
>
> Ah, about that:
>
> the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
> in the following way [0]:
> |	bw =3D info2 & 3;
>
> the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by [1]=
:
> |	txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>
> ATH10K_HW_BW is a macro defined as [2]:
> |	#define ATH10K_HW_BW(flags)		(((flags) >> 3) & 0x3)
>
> In both cases the bandwidth values already are limited to 0-3 by
> the "and 3" operation.

Until someone changes that part of the code (and the firmware
interface). IMHO a switch is safer as there we don't have any risk of
out of bands access.

--=20
Kalle Valo=

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Christian Lamparter]

On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
> Christian Lamparter <chunkeey@gmail.com> writes:
> 
> > On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:
> >> a additional array bounds check would be good
> >
> > Ah, about that:
> >
> > the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
> > in the following way [0]:
> > |	bw = info2 & 3;
> >
> > the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by [1]:
> > |	txrate.bw = ATH10K_HW_BW(peer_stats->flags);
> >
> > ATH10K_HW_BW is a macro defined as [2]:
> > |	#define ATH10K_HW_BW(flags)		(((flags) >> 3) & 0x3)
> >
> > In both cases the bandwidth values already are limited to 0-3 by
> > the "and 3" operation.
> 
> Until someone changes that part of the code (and the firmware
> interface). IMHO a switch is safer as there we don't have any risk of
> out of bands access.

The kbuild-bot/CI can catch this too. 

For example, it will look like this:
drivers/net/wireless/ath/ath10k//htt_rx.c:710:52: warning: invalid access past the end of 'ath10k_bw_to_mac80211' (4 4)

BTW:
Have you noticed:

<https://github.com/lede-project/source/blob/master/package/kernel/mac80211/patches/319-ath10k-fix-recent-bandwidth-conversion-bug.patch>

Is this really your signed-off-by or not?

In any case, you - as the maintainer - can modify the patch as
you see fit. So, please do so.

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Kalle Valo]

Christian Lamparter <chunkeey@gmail.com> writes:

> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>> Christian Lamparter <chunkeey@gmail.com> writes:
>>=20
>> > On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wro=
te:
>> >> a additional array bounds check would be good
>> >
>> > Ah, about that:
>> >
>> > the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
>> > in the following way [0]:
>> > |	bw =3D info2 & 3;
>> >
>> > the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by =
[1]:
>> > |	txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>> >
>> > ATH10K_HW_BW is a macro defined as [2]:
>> > |	#define ATH10K_HW_BW(flags)		(((flags) >> 3) & 0x3)
>> >
>> > In both cases the bandwidth values already are limited to 0-3 by
>> > the "and 3" operation.
>>=20
>> Until someone changes that part of the code (and the firmware
>> interface). IMHO a switch is safer as there we don't have any risk of
>> out of bands access.
>
> The kbuild-bot/CI can catch this too.=20
>
> For example, it will look like this:
> drivers/net/wireless/ath/ath10k//htt_rx.c:710:52: warning: invalid
> access past the end of 'ath10k_bw_to_mac80211' (4 4)

Sure, but after reading about all these security vulnerabilities I have
become even more cautious and try to avoid all tricky stuff.

> BTW:
> Have you noticed:
>
> <https://github.com/lede-project/source/blob/master/package/kernel/mac802=
11/patches/319-ath10k-fix-recent-bandwidth-conversion-bug.patch>
>
> Is this really your signed-off-by or not?

I suspect that patch is taken from my pending branch.

> In any case, you - as the maintainer - can modify the patch as
> you see fit. So, please do so.

Ok, we'll send v2.

--=20
Kalle Valo=

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Rafał Miłecki]

On 14 December 2017 at 14:21, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Christian Lamparter <chunkeey@gmail.com> writes:
>
>> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>>> Christian Lamparter <chunkeey@gmail.com> writes:
>>>
>>> > On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wr=
ote:
>>> >> a additional array bounds check would be good
>>> >
>>> > Ah, about that:
>>> >
>>> > the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
>>> > in the following way [0]:
>>> > |  bw =3D info2 & 3;
>>> >
>>> > the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by=
 [1]:
>>> > |  txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>>> >
>>> > ATH10K_HW_BW is a macro defined as [2]:
>>> > |  #define ATH10K_HW_BW(flags)             (((flags) >> 3) & 0x3)
>>> >
>>> > In both cases the bandwidth values already are limited to 0-3 by
>>> > the "and 3" operation.
>>>
>>> Until someone changes that part of the code (and the firmware
>>> interface). IMHO a switch is safer as there we don't have any risk of
>>> out of bands access.
>>
>> The kbuild-bot/CI can catch this too.
>>
>> For example, it will look like this:
>> drivers/net/wireless/ath/ath10k//htt_rx.c:710:52: warning: invalid
>> access past the end of 'ath10k_bw_to_mac80211' (4 4)
>
> Sure, but after reading about all these security vulnerabilities I have
> become even more cautious and try to avoid all tricky stuff.
>
>> BTW:
>> Have you noticed:
>>
>> <https://github.com/lede-project/source/blob/master/package/kernel/mac80=
211/patches/319-ath10k-fix-recent-bandwidth-conversion-bug.patch>
>>
>> Is this really your signed-off-by or not?
>
> I suspect that patch is taken from my pending branch.
>
>> In any case, you - as the maintainer - can modify the patch as
>> you see fit. So, please do so.
>
> Ok, we'll send v2.

Hi Kalle,

I'm trying to figure out the fate of that LEDE's patch. I don't think
you ever sent V2.

Is that fix still needed? Are you planning to send V2?

--=20
Rafa=C5=82

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Kalle Valo]

Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:

> On 14 December 2017 at 14:21, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Christian Lamparter <chunkeey@gmail.com> writes:
>>
>>> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>>>> Christian Lamparter <chunkeey@gmail.com> writes:
>>>>
>>>> > On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall w=
rote:
>>>> >> a additional array bounds check would be good
>>>> >
>>>> > Ah, about that:
>>>> >
>>>> > the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
>>>> > in the following way [0]:
>>>> > |  bw =3D info2 & 3;
>>>> >
>>>> > the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set b=
y [1]:
>>>> > |  txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>>>> >
>>>> > ATH10K_HW_BW is a macro defined as [2]:
>>>> > |  #define ATH10K_HW_BW(flags)             (((flags) >> 3) & 0x3)
>>>> >
>>>> > In both cases the bandwidth values already are limited to 0-3 by
>>>> > the "and 3" operation.
>>>>
>>>> Until someone changes that part of the code (and the firmware
>>>> interface). IMHO a switch is safer as there we don't have any risk of
>>>> out of bands access.
>>>
>>> The kbuild-bot/CI can catch this too.
>>>
>>> For example, it will look like this:
>>> drivers/net/wireless/ath/ath10k//htt_rx.c:710:52: warning: invalid
>>> access past the end of 'ath10k_bw_to_mac80211' (4 4)
>>
>> Sure, but after reading about all these security vulnerabilities I have
>> become even more cautious and try to avoid all tricky stuff.
>>
>>> BTW:
>>> Have you noticed:
>>>
>>> <https://github.com/lede-project/source/blob/master/package/kernel/mac8=
0211/patches/319-ath10k-fix-recent-bandwidth-conversion-bug.patch>
>>>
>>> Is this really your signed-off-by or not?
>>
>> I suspect that patch is taken from my pending branch.
>>
>>> In any case, you - as the maintainer - can modify the patch as
>>> you see fit. So, please do so.
>>
>> Ok, we'll send v2.
>
> Hi Kalle,
>
> I'm trying to figure out the fate of that LEDE's patch. I don't think
> you ever sent V2.
>
> Is that fix still needed? Are you planning to send V2?

Anil now sent v2 (he just forgot to mark it as such):

https://patchwork.kernel.org/patch/10273445/

Thanks for the reminder.

--=20
Kalle Valo

Re: [PATCH] ath10k: fix recent bandwidth conversion bug

[Rafał Miłecki]

On 11 March 2018 at 08:12, Kalle Valo <kvalo@codeaurora.org> wrote:
> Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
>
>> On 14 December 2017 at 14:21, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>> Christian Lamparter <chunkeey@gmail.com> writes:
>>>
>>>> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>>>>> Christian Lamparter <chunkeey@gmail.com> writes:
>>>>>
>>>>> > On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall =
wrote:
>>>>> >> a additional array bounds check would be good
>>>>> >
>>>>> > Ah, about that:
>>>>> >
>>>>> > the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
>>>>> > in the following way [0]:
>>>>> > |  bw =3D info2 & 3;
>>>>> >
>>>>> > the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set =
by [1]:
>>>>> > |  txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>>>>> >
>>>>> > ATH10K_HW_BW is a macro defined as [2]:
>>>>> > |  #define ATH10K_HW_BW(flags)             (((flags) >> 3) & 0x3)
>>>>> >
>>>>> > In both cases the bandwidth values already are limited to 0-3 by
>>>>> > the "and 3" operation.
>>>>>
>>>>> Until someone changes that part of the code (and the firmware
>>>>> interface). IMHO a switch is safer as there we don't have any risk of
>>>>> out of bands access.
>>>>
>>>> The kbuild-bot/CI can catch this too.
>>>>
>>>> For example, it will look like this:
>>>> drivers/net/wireless/ath/ath10k//htt_rx.c:710:52: warning: invalid
>>>> access past the end of 'ath10k_bw_to_mac80211' (4 4)
>>>
>>> Sure, but after reading about all these security vulnerabilities I have
>>> become even more cautious and try to avoid all tricky stuff.
>>>
>>>> BTW:
>>>> Have you noticed:
>>>>
>>>> <https://github.com/lede-project/source/blob/master/package/kernel/mac=
80211/patches/319-ath10k-fix-recent-bandwidth-conversion-bug.patch>
>>>>
>>>> Is this really your signed-off-by or not?
>>>
>>> I suspect that patch is taken from my pending branch.
>>>
>>>> In any case, you - as the maintainer - can modify the patch as
>>>> you see fit. So, please do so.
>>>
>>> Ok, we'll send v2.
>>
>> Hi Kalle,
>>
>> I'm trying to figure out the fate of that LEDE's patch. I don't think
>> you ever sent V2.
>>
>> Is that fix still needed? Are you planning to send V2?
>
> Anil now sent v2 (he just forgot to mark it as such):
>
> https://patchwork.kernel.org/patch/10273445/
>
> Thanks for the reminder.

Thanks!

--=20
Rafa=C5=82

[PATCH] ath10k: fix recent bandwidth conversion bug

[Anilkumar Kolli]

From: Christian Lamparter <chunkeey@gmail.com>

The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
the index of RATE_INFO_BW_20, but the updates to ath10k missed
the special bandwidth calculation case in
ath10k_update_per_peer_tx_stats().

This will fix below warning,

 WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254
 cfg80211_calculate_bitrate+0x174/0x220
 invalid rate bw=1, mcs=9, nss=2

 (unwind_backtrace) from
 (cfg80211_calculate_bitrate+0x174/0x220)
 (cfg80211_calculate_bitrate) from
 (nl80211_put_sta_rate+0x44/0x1dc)from
 (nl80211_put_sta_rate) from
 (nl80211_send_station+0x388/0xaf0)
 (nl80211_get_station+0xa8/0xec)
 [ end trace da8257d6a850e91a ]

Fixes: 842be75c77cb ("cfg80211: make RATE_INFO_BW_20 the default")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c |   43 +++++++++++++++++-------------
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6d96f9560950..47d1f2f6c6bb 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2005-2011 Atheros Communications Inc.
  * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -723,6 +724,28 @@ struct amsdu_subframe_hdr {
 
 #define GROUP_ID_IS_SU_MIMO(x) ((x) == 0 || (x) == 63)
 
+static inline u8 ath10k_bw_to_mac80211_bw(u8 bw)
+{
+	u8 ret = 0;
+
+	switch (bw) {
+	case 0:
+		ret = RATE_INFO_BW_20;
+		break;
+	case 1:
+		ret = RATE_INFO_BW_40;
+		break;
+	case 2:
+		ret = RATE_INFO_BW_80;
+		break;
+	case 3:
+		ret = RATE_INFO_BW_160;
+		break;
+	}
+
+	return ret;
+}
+
 static void ath10k_htt_rx_h_rates(struct ath10k *ar,
 				  struct ieee80211_rx_status *status,
 				  struct htt_rx_desc *rxd)
@@ -825,23 +848,7 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
 		if (sgi)
 			status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
 
-		switch (bw) {
-		/* 20MHZ */
-		case 0:
-			break;
-		/* 40MHZ */
-		case 1:
-			status->bw = RATE_INFO_BW_40;
-			break;
-		/* 80MHZ */
-		case 2:
-			status->bw = RATE_INFO_BW_80;
-			break;
-		case 3:
-			status->bw = RATE_INFO_BW_160;
-			break;
-		}
-
+		status->bw = ath10k_bw_to_mac80211_bw(bw);
 		status->encoding = RX_ENC_VHT;
 		break;
 	default:
@@ -2499,7 +2506,7 @@ static inline bool is_valid_legacy_rate(u8 rate)
 		arsta->txrate.flags |= RATE_INFO_FLAGS_SHORT_GI;
 
 	arsta->txrate.nss = txrate.nss;
-	arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+	arsta->txrate.bw = ath10k_bw_to_mac80211_bw(txrate.bw);
 }
 
 static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
-- 
1.7.9.5