Re: [PATCH v3 1/2] ath9k: fix use-after-free in ath9k_hif_usb_rx_cb

[Pavel Skripkin]

Hi Toke,

On 2/8/22 17:47, Toke Høiland-Jørgensen wrote:
> Pavel Skripkin <paskripkin@xxxxxxxxx> writes:
>
> > Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb(). The
> > problem was in incorrect htc_handle->drv_priv initialization.
> >
> > Probable call trace which can trigger use-after-free:
> >
> > ath9k_htc_probe_device()
> >   /* htc_handle->drv_priv = priv; */
> >   ath9k_htc_wait_for_target()      <--- Failed
> >   ieee80211_free_hw()		   <--- priv pointer is freed
> >
> > <IRQ>
> > ...
> > ath9k_hif_usb_rx_cb()
> >   ath9k_hif_usb_rx_stream()
> >    RX_STAT_INC()		<--- htc_handle->drv_priv access
> >
> > In order to not add fancy protection for drv_priv we can move
> > htc_handle->drv_priv initialization at the end of the
> > ath9k_htc_probe_device() and add helper macro to make
> > all *_STAT_* macros NULL save.
>
> I'm not too familiar with how the initialisation flow of an ath9k_htc
> device works. Looking at htc_handle->drv_priv there seems to
> be three other functions apart from the stat counters that dereference
> it:
>
> ath9k_htc_suspend()
> ath9k_htc_resume()
> ath9k_hif_usb_disconnect()
>
> What guarantees that none of these will be called midway through
> ath9k_htc_probe_device() (which would lead to a NULL deref after this
> change)?

IIUC, situation you are talking about may happen even without my change.
I was thinking, that ath9k_htc_probe_device() is the real ->probe() 
function, but things look a bit more tricky.


So, the ->probe() function may be completed before 
ath9k_htc_probe_device() is called, because it's called from fw loader 
callback function. If ->probe() is completed, than we can call 
->suspend(), ->resume() and others usb callbacks, right? And we can meet 
NULL defer even if we leave drv_priv = priv initialization on it's place.

Please, correct me if I am wrong somewhere :)




With regards,
Pavel Skripkin