Re: [PATCH 2/2] ath9k: fix ath_tx_process_buffer() potential null ptr dereference

[Shuah Khan]

On 2/17/21 7:56 AM, Shuah Khan wrote:
> On 2/17/21 12:30 AM, Kalle Valo wrote:
> > Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> writes:
> >
> > > On 2/16/21 12:53 AM, Felix Fietkau wrote:
> > > > On 2021-02-16 08:03, Kalle Valo wrote:
> > > > > Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx>
> > > > > > Signed-off-by: Kalle Valo <kvalo@xxxxxxxxxxxxxx>
> > > > >
> > > > > 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