Messages in this thread | | | Date | Tue, 8 Feb 2022 18:48:24 +0300 | Subject | Re: [PATCH v3 1/2] ath9k: fix use-after-free in ath9k_hif_usb_rx_cb | From | Pavel Skripkin <> |
| |
Hi Toke,
On 2/8/22 17:47, Toke Høiland-Jørgensen wrote: > Pavel Skripkin <paskripkin@gmail.com> 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
| |