Skip to main content
VulnerabilityPublished Updated

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

Affects Linux kernelSource CVE Database V5

0
Compare

Not known to be exploited · fixed in dad9f96945d77ecd4708f730c06ef54dcd8cc057 : update Linux kernel when convenient.

Data as of 6 Nov 2026, 17:19 UTC

Severity
Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

Thin evidence

One scorer or none
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-11-06.

Patch
Available – fixed in dad9f96945d77ecd4708f730c06ef54dcd8cc057, 063497cc9f320ab71a7a937c3bc0a23e630aefe2, 48de0c6952192b0771fca468df4364d11ec74ad9 +5

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ e904cf6fe23022cde4e0ea9d41601411a315a3dc, < dad9f96945d77ecd4708f730c06ef54dcd8cc057
Fixed in
  • dad9f96945d77ecd4708f730c06ef54dcd8cc057
LinuxLinuxAffected
  • ≥ e904cf6fe23022cde4e0ea9d41601411a315a3dc, < 063497cc9f320ab71a7a937c3bc0a23e630aefe2
Fixed in
  • 063497cc9f320ab71a7a937c3bc0a23e630aefe2
LinuxLinuxAffected
  • ≥ e904cf6fe23022cde4e0ea9d41601411a315a3dc, < 48de0c6952192b0771fca468df4364d11ec74ad9
Fixed in
  • 48de0c6952192b0771fca468df4364d11ec74ad9
LinuxLinuxAffected
  • ≥ e904cf6fe23022cde4e0ea9d41601411a315a3dc, < 48a69cedde7388294e4ea6fd804156cd62bc04fc
Fixed in
  • 48a69cedde7388294e4ea6fd804156cd62bc04fc
LinuxLinuxAffected
  • ≥ e904cf6fe23022cde4e0ea9d41601411a315a3dc, < 47ed81aaa7f94d9808f4719e78a760c2ec1e6c86
Fixed in
  • 47ed81aaa7f94d9808f4719e78a760c2ec1e6c86
LinuxLinuxAffected
  • ≥ e904cf6fe23022cde4e0ea9d41601411a315a3dc, < 10b0ce629123a3737b4eda50188f73bb7be7b68b
Fixed in
  • 10b0ce629123a3737b4eda50188f73bb7be7b68b

Description

In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n", hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the "events" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev 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 ath9k_htc 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.

References

Community reviews

Loading reviews…