On 11 March 2018 at 08:12, Kalle Valo <kv...@codeaurora.org> wrote:
> Rafał Miłecki <zaj...@gmail.com> writes:
>
>> On 14 December 2017 at 14:21, Kalle Valo <kv...@qca.qualcomm.com> wrote:
>>> Christian Lamparter <chunk...@gmail.com> writes:
>>>
>>>> On Monday, November 20, 2017 11:57:21 AM CET Kalle Valo wrote:
>>>>> Christian Lamparter <chunk...@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)
>>>
>>> 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/mac80211/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!

-- 
Rafał

Reply via email to