[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d70b0ab-0627-74a1-3602-98a7c71b871a@linuxfoundation.org>
Date: Wed, 17 Feb 2021 13:28:25 -0700
From: Shuah Khan <skhan@...uxfoundation.org>
To: Kalle Valo <kvalo@...eaurora.org>, Felix Fietkau <nbd@....name>
Cc: davem@...emloft.net, kuba@...nel.org, ath9k-devel@....qualcomm.com,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH 2/2] ath9k: fix ath_tx_process_buffer() potential null ptr
dereference
On 2/17/21 7:56 AM, Shuah Khan wrote:
> On 2/17/21 12:30 AM, Kalle Valo wrote:
>> Shuah Khan <skhan@...uxfoundation.org> writes:
>>
>>> On 2/16/21 12:53 AM, Felix Fietkau wrote:
>>>>
>>>> On 2021-02-16 08:03, Kalle Valo wrote:
>>>>> Shuah Khan <skhan@...uxfoundation.org> 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 <skhan@...uxfoundation.org>
>>>>>> Signed-off-by: Kalle Valo <kvalo@...eaurora.org>
>>>>>
>>>>> 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
Powered by blists - more mailing lists