Messages in this thread | | | Subject | Re: [PATCH 2/2] ath9k: fix ath_tx_process_buffer() potential null ptr dereference | From | Shuah Khan <> | Date | Wed, 17 Feb 2021 13:28:25 -0700 |
| |
On 2/17/21 7:56 AM, Shuah Khan wrote: > On 2/17/21 12:30 AM, Kalle Valo wrote: >> Shuah Khan <skhan@linuxfoundation.org> writes: >> >>> On 2/16/21 12:53 AM, Felix Fietkau wrote: >>>> >>>> On 2021-02-16 08:03, Kalle Valo wrote: >>>>> Shuah Khan <skhan@linuxfoundation.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@linuxfoundation.org> >>>>>> Signed-off-by: Kalle Valo <kvalo@codeaurora.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
| |