Re: [PATCH 1/1] wifi: ath9k: hif_usb: fix memory leak of remain_skbs

Fedor Pchelkin [off-list ref] writes:

On 16.02.2023 19:15, Toke Høiland-Jørgensen wrote:
 > Erm, does this actually fix the leak? AFAICT, ath9k_hif_usb_dev_deinit()
 > is only called on the error path of ath9k_hif_usb_firmware_cb(), not
 > when the device is subsequently torn down in
 > ath9k_htc_disconnect_device()?

ath9k_hif_usb_dev_deinit() is also called inside
ath9k_hif_usb_disconnect().

No it's not, as of:

f099c5c9e2ba ("wifi: ath9k: Fix use-after-free in ath9k_hif_usb_disconnect()")

I guess you're looking at an older tree? Please base your patches on an
up-to-date ath-next tree.

I see it to be the only place wherehif_dev is freed (apart from an
early error path), so the current patchimplementation actually fixes
the leak. However, as you have noticed, itis not probably the best
place to put the deallocation: we need to clearthe cached skb not only
when freeing the device but in urbs deallocationcase, too - in order
to avoid its irrelevant processing later.

 > I think the right place to put this is probably inside
 > ath9k_hif_usb_dealloc_urbs()? That gets called on USB suspend as well,
 > but it seems to me that if we're suspending the device to an extent that
 > we're deallocating the urbs, we should be clearing out the cached skb in
 > remain_skb anyway?
 >
 > -Toke

Thank you for the advice! As I can see, remain_skb makes sense when
receiving two consecutive urbs which are logically linked together, i.e.
a specific data field from the first skb indicates a cached skb to be
allocated, memcpy'd with some data and subsequently processed in the
next call to rx callback (see 6ce708f54cc8 ("ath9k: Fix out-of-bound
memcpy in ath9k_hif_usb_rx_stream")). Urbs deallocation, I suppose,
makes that link irrelevant.

So I agree with you that remain_skb freeing should be done when
deallocating the urbs. I would just place that specifically into
ath9k_hif_usb_dealloc_rx_urbs() as remain_skb is associated with rx
urbs.

SGTM.

RX_STAT_INC(hif_dev, skb_dropped), I think, should be also called when
freeing afilled remain_skb?

Well, if this is mostly something that happens if the device is going
away I'm not sure that anyone will actually see that; but I suppose if
it happens on suspend, the stat increase may be useful, and it shouldn't
hurt otherwise, so sure, let's add that :)

-Toke