CVE-2026-68363: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: hifusb: don't dereference hifdev after re-arming firmware request

ath9khifrequestfirmware() re-arms an asynchronous firmware load via requestfirmwarenowait(), passing hifdev as the completion context, and then still dereferences hifdev:

devinfo(&hifdev->udev->dev, "ath9khtc: Firmware %s requested\n", hifdev->fwname);

The re-armed callback ath9khifusbfirmwarecb() runs on the "events" workqueue and, when the firmware is missing, walks the retry chain into ath9khifusbfirmwarefail() -> completeall(&hifdev->fwdone). That releases the waitforcompletion(&hifdev->fwdone) in a concurrent ath9khifusbdisconnect(), which then kfree()s hifdev. The trailing devinfo() in the frame that re-armed the request can therefore read freed memory (hifdev->udev, the first field of struct hifdeviceusb):

BUG: KASAN: slab-use-after-free in ath9khifrequestfirmware Read of size 8 ... by task kworker/... ath9khifrequestfirmware ath9khifusbfirmwarecb drivers/net/wireless/ath/ath9k/hifusb.c:1247 requestfirmwareworkfunc Allocated by ...: ath9khifusbprobe drivers/net/wireless/ath/ath9k/hifusb.c Freed by ...: ath9khifusbdisconnect -> kfree drivers/net/wireless/ath/ath9k/hifusb.c

The fwdone barrier only makes disconnect wait for the firmware chain to terminate; it does not protect the outer ath9khifrequestfirmware() frame that re-armed the request and keeps touching hifdev afterwards.

Drop the post-request devinfo(): it is the only use of hifdev after the async request is armed, and it is purely informational (the deverr() on the failure path runs only when requestfirmwarenowait() did not arm a callback, so hifdev is still alive there).

This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9khtc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.