From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-68363][MODERATE 7.0] wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request [ Upstream Date: Mon, 10 Aug 2026 10:54:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-68363 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 5 X-AL-KERNEL-ActionableScore-Lower: 2 X-AL-KERNEL-Commit: 7f184ca38a90889f3f6665ff96748b95da39dbee List-Id: CVE: CVE-2026-68363 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: NO Patch: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request [ Upstream Commit: 7f184ca38a90889f3f6665ff96748b95da39dbee Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7f184ca38a90889f3f6665ff96748b95da39dbee Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-68363 Analysis date: Mon, 10 Aug 2026 10:54:56 -0400 ActionableScore: 5 ActionableScore lower bound: 2 Actionable bucket: Actionable Moderate at minimum / Strong Important not established Manual review required: YES Summary: A race in the ath9k hif_usb asynchronous firmware request path can leave hif_dev freed by disconnect while still being read by a trailing log statement, causing a kernel use-after-free crash and requiring manual review due to the lifetime-corruption class. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-68363 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-68363 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE 7.0 Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-68363 MODERATE CHECK WITH IMPACT FROM ORIG NN IMPORTANT Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';*CWE-416;CWE-362;*CWE-672;Other CVSS 'AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H';Other CVSS 'AV:P/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '5.8';DESCR 'A use after free read can occur in the ath9k hif_usb firmware loading path because ath9k_hif_request_firmware() re arms an asynchronous request with hif_dev as callback context and then still dereferences hif_dev for an informational log. If the firmware request fails, the callback can complete fw_done and allow a concurrent disconnect path to free hif_dev before the original request function reaches the trailing dev_info access. For the CVSS the PR:N value is used for the paranoid physical device scenario because a malicious USB device can trigger the driver path without privileges on the victim, assuming the device can be attached. The issue is not network reachable and requires USB device presence or equivalent local USB gadget emulation. Impact is at least denial of service via kernel warning or crash. In the worst still defensible interpretation, limited confidentiality or integrity impact is possible because this is a kernel UAF read race, but the patch context does not show an arbitrary write primitive.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate at minimum / Strong Important not established (with actual score 4) YES REMOTE READ DANGER USB RACE UAF NETWORK KERNEL_PANIC_PLUS_UAF HARDWARE SYZBOT LOWERED_FROM_HIGH_BASED_ON_GUESSCVSS DECREASED_TO_MODERATEREG_BASED_ON_ACTIONABLESCORELESSTHAN5 NO NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=5 ActionableScoreLower=2 ## 1. ActionableScore * Conservative score: 2 * Paranoid score: 5 * Final recommended bucket: **Actionable Moderate at minimum / Strong Important not established**:: ## 2. Signal breakdown Conservative scoring: * +1 Firmware-mediated external influence: a malicious or failing USB ath9k_htc device can influence the firmware-load and disconnect sequence. * +1 Memory corruption, weak primitive: this is a race-dependent UAF read, but the stale access is an informational `dev_info()` dereference, not a demonstrated write or callback control primitive. * +1 Real lifetime corruption: `hif_dev` can be freed by disconnect while the outer firmware request frame still uses it. * +1 Reliable kernel crash / strong DoS: KASAN reports slab-use-after-free, and the reproducer can trigger the crash when the race window is widened. * +1 Privileged kernel/device-management lifetime path: the bug is in USB WiFi driver firmware and disconnect lifetime handling. * -1 Hard or unreliable race: the described race window is sub-microsecond and timing-sensitive. * -2 Physical-only or rare hardware-only condition: realistic external triggering requires a physical USB device or equivalent USB gadget setup. Paranoid scoring: * +1 Local unprivileged trigger: counted only for environments where an untrusted local actor can control USB gadget emulation or attach controlled USB devices. * +1 Firmware-mediated external influence: the trigger is device/firmware-load mediated rather than network reachable. * +1 Memory corruption, weak primitive: UAF read after free. * +1 Real lifetime corruption: async completion and disconnect lifetime mismatch. * +1 Reliable kernel crash / strong DoS: reproducible UAF crash under KASAN conditions. * +1 Privileged kernel/device-management lifetime path: driver disconnect and firmware callback path. * -1 Hard race: timing remains difficult. No strong LPE bonus is awarded. The patch does not show attacker-controlled reclaim, stale object replacement, write-after-free, callback dispatch through freed memory, type confusion, or refcount takeover. ## 3. Reachability analysis The bug can be triggered by an ath9k_htc USB device whose firmware request fails while a disconnect races with the asynchronous firmware callback. It is not network reachable through WiFi traffic. The realistic attacker model is either physical USB access or local control over USB gadget emulation. Namespaces and containers only matter if they provide practical access to USB gadget or device attach/detach operations. In normal deployments this is not available to an unprivileged container. In specialized testing, embedded, or USB-gadget-enabled environments, local reachability may be stronger. The path is not a broad default network surface. It depends on the ath9k_htc USB driver, firmware failure behavior, and connect/disconnect timing. Call-site confidence: high. The commit message describes the allocation, callback, completion, disconnect, free, and stale dereference path. ## 4. Severity interpretation This behaves more like an Actionable Moderate memory-lifetime bug than an Important-class vulnerability. The theoretical risk is higher than a pure NULL dereference because it is a real kernel use-after-free. However, the visible primitive is a read-only stale dereference in an informational logging path, with no demonstrated reclaim or write primitive. Realistic impact is kernel crash or warning/oops. Privilege escalation is not strongly supported by the patch context, but manual review is justified because kernel UAF races can be underestimated during early triage. ## 5. One-sentence report phrase A race in the ath9k hif_usb asynchronous firmware request path can leave hif_dev freed by disconnect while still being read by a trailing log statement, causing a kernel use-after-free crash and requiring manual review due to the lifetime-corruption class. ## 6. Manual review recommendation MANUAL CHECK REQUIRED Reason: this is a confirmed race-based kernel use-after-free with a reproducer and a real lifetime mismatch, even though the currently visible primitive is read-only and the most likely practical impact is DoS. ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request [ Upstream Commit: 7f184ca38a90889f3f6665ff96748b95da39dbee Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7f184ca38a90889f3f6665ff96748b95da39dbee Changed files: drivers/net/wireless/ath/ath9k/hif_usb.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7f184ca38a90889f3f6665ff96748b95da39dbee ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-68363 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-68363 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H The Best / paranoid CVSS score: 5.8 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 2 Paranoid ActionableScore: 5 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: NO Published priority for this report (same as in Subject): MODERATE 7.0 These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).