Shuah Khan <[email protected]> writes:
> On 2/16/21 12:53 AM, Felix Fietkau wrote:
>>
>> On 2021-02-16 08:03, Kalle Valo wrote:
>>> Shuah Khan <[email protected]> wrote:
>>>
>>>> ath_tx_process_buffer() references ieee80211_find_sta_by_ifaddr()
>>>> return pointer (sta) outside null check. Fix it by moving the code
>>>> block under the null check.
>>>>
>>>> This problem was found while reviewing code to debug RCU warn from
>>>> ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit
>>>> of other callers of ieee80211_find_sta_by_ifaddr() that don't hold
>>>> RCU read lock.
>>>>
>>>> Signed-off-by: Shuah Khan <[email protected]>
>>>> Signed-off-by: Kalle Valo <[email protected]>
>>>
>>> Patch applied to ath-next branch of ath.git, thanks.
>>>
>>> a56c14bb21b2 ath9k: fix ath_tx_process_buffer() potential null ptr dereference
>> I just took another look at this patch, and it is completely bogus.
>> Not only does the stated reason not make any sense (sta is simply passed
>> to other functions, not dereferenced without checks), but this also
>> introduces a horrible memory leak by skipping buffer completion if sta
>> is NULL.
>> Please drop it, the code is fine as-is.
>
> A comment describing what you said here might be a good addition to this
> comment block though.
Shuah, can you send a followup patch which reverts your change and adds
the comment? I try to avoid rebasing my trees.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On 2/17/21 12:30 AM, Kalle Valo wrote:
> Shuah Khan <[email protected]> writes:
>
>> On 2/16/21 12:53 AM, Felix Fietkau wrote:
>>>
>>> On 2021-02-16 08:03, Kalle Valo wrote:
>>>> Shuah Khan <[email protected]> wrote:
>>>>
>>>>> ath_tx_process_buffer() references ieee80211_find_sta_by_ifaddr()
>>>>> return pointer (sta) outside null check. Fix it by moving the code
>>>>> block under the null check.
>>>>>
>>>>> This problem was found while reviewing code to debug RCU warn from
>>>>> ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit
>>>>> of other callers of ieee80211_find_sta_by_ifaddr() that don't hold
>>>>> RCU read lock.
>>>>>
>>>>> Signed-off-by: Shuah Khan <[email protected]>
>>>>> Signed-off-by: Kalle Valo <[email protected]>
>>>>
>>>> Patch applied to ath-next branch of ath.git, thanks.
>>>>
>>>> a56c14bb21b2 ath9k: fix ath_tx_process_buffer() potential null ptr dereference
>>> I just took another look at this patch, and it is completely bogus.
>>> Not only does the stated reason not make any sense (sta is simply passed
>>> to other functions, not dereferenced without checks), but this also
>>> introduces a horrible memory leak by skipping buffer completion if sta
>>> is NULL.
>>> Please drop it, the code is fine as-is.
>>
>> A comment describing what you said here might be a good addition to this
>> comment block though.
>
> Shuah, can you send a followup patch which reverts your change and adds
> the comment? I try to avoid rebasing my trees.
>
I can do that.
thanks,
-- Shuah
On 2/17/21 7:56 AM, Shuah Khan wrote:
> On 2/17/21 12:30 AM, Kalle Valo wrote:
>> Shuah Khan <[email protected]> writes:
>>
>>> On 2/16/21 12:53 AM, Felix Fietkau wrote:
>>>>
>>>> On 2021-02-16 08:03, Kalle Valo wrote:
>>>>> Shuah Khan <[email protected]> wrote:
>>>>>
>>>>>> ath_tx_process_buffer() references ieee80211_find_sta_by_ifaddr()
>>>>>> return pointer (sta) outside null check. Fix it by moving the code
>>>>>> block under the null check.
>>>>>>
>>>>>> This problem was found while reviewing code to debug RCU warn from
>>>>>> ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit
>>>>>> of other callers of ieee80211_find_sta_by_ifaddr() that don't hold
>>>>>> RCU read lock.
>>>>>>
>>>>>> Signed-off-by: Shuah Khan <[email protected]>
>>>>>> Signed-off-by: Kalle Valo <[email protected]>
>>>>>
>>>>> Patch applied to ath-next branch of ath.git, thanks.
>>>>>
>>>>> a56c14bb21b2 ath9k: fix ath_tx_process_buffer() potential null ptr
>>>>> dereference
>>>> I just took another look at this patch, and it is completely bogus.
>>>> Not only does the stated reason not make any sense (sta is simply
>>>> passed
>>>> to other functions, not dereferenced without checks), but this also
>>>> introduces a horrible memory leak by skipping buffer completion if sta
>>>> is NULL.
>>>> Please drop it, the code is fine as-is.
>>>
Felix,
I looked at the code path again and found the following path that
can become a potential dereference downstream. My concern is
about potential dereference downstream.
First path: ath_tx_complete_buf()
1. ath_tx_process_buffer() passes sta to ath_tx_complete_buf()
2. ath_tx_complete_buf() doesn't check or dereference sta
Passes it on to ath_tx_complete()
3. ath_tx_complete() doesn't check or dereference sta, but assigns
it to tx_info->status.status_driver_data[0]
tx_info->status.status_driver_data[0] = sta;
ath_tx_complete_buf() should be fixed to check sta perhaps?
This assignment without checking could lead to dereference at some
point in the future.
Second path: ath_tx_complete_aggr()
1. ath_tx_process_buffer() passes sta to ath_tx_complete_aggr()
2. No problems in this path as ath_tx_complete_aggr() checks
sta before use.
I can send the revert as it moves more code than necessary under
the null check. As you pointed out, it could lead to memory leak.
Not knowing this code well, I can't really tell where. However,
my original concern is valid for ath_tx_complete_buf() path.
Sending revert as requested.
thanks,
-- Shuah