From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-93117][MODERATE 7.0] usb: fix UAF when probe runs concurrent to dyn ID removal [ Upstream Date: Thu, 17 Sep 2026 22:54:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-93117 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 5 X-AL-KERNEL-ActionableScore-Lower: 4 X-AL-KERNEL-Commit: 9b82ddf76827e2a8ff033a8131ecf24f2d6cae26 List-Id: CVE: CVE-2026-93117 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: usb: fix UAF when probe runs concurrent to dyn ID removal [ Upstream Commit: 9b82ddf76827e2a8ff033a8131ecf24f2d6cae26 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b82ddf76827e2a8ff033a8131ecf24f2d6cae26 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93117 Analysis date: Thu, 17 Sep 2026 22:54:24 -0400 ActionableScore: 5 ActionableScore lower bound: 4 Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review Manual review required: YES Summary: No one-sentence report phrase was found. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-93117 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93117 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-93117 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-93117 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-362;CWE-367;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H';Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H';BEST CVSS score: '7';DESCR 'A use-after-free can occur in the USB driver core because usb_match_dynamic_id returned a pointer to a dynamic usb_device_id that is only protected while usb_dynids_lock is held. If remove_id_store removes the same dynamic ID through sysfs while usb_probe_interface is still using the returned pointer, the probe path may pass a stale usb_device_id to the driver callback. For the CVSS the PR:H value is used because reliable triggering requires write access to the USB driver dynamic ID sysfs interface, which is normally restricted to an administrator. The issue is not network reachable and requires a local control plane action plus a race with device probing. Impact is at least denial of service via kernel crash and in the paranoid case may include broader confidentiality or integrity impact because the bug class is kernel use-after-free.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5) YES USB UAF HARDWARE LINUS KPANIC NO NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=5 ActionableScoreLower=4 PrimitiveClass=CLASS_B RealUAF=YES HostAdminRequired=UNKNOWN NamespaceScopedPrivilege=NO ImportantCandidate=YES ManualReview=REQUIRED AutoDowngradeAllowed=NO 1. ActionableScore * Raw conservative score: 4 * Conservative score: 4 * Raw paranoid score: 5 * Paranoid score: 5 * Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**:: No floor or cap changed the score. The paranoid score is emitted as the final ActionableScore because the UAF is real and the stale object is passed into a driver probe callback, leaving exploitation leverage beyond a simple crash unresolved. 2. Signal breakdown Positive signals: * +2 Real UAF / active lifetime violation: `usb_match_dynamic_id()` returned `&dynid->id` while the lifetime of `dynid` was only protected while `usb_dynids_lock` was held. `remove_id_store` can free the node after the lock is released. * +1 Reliable kernel crash / strong DoS: a stale `usb_device_id` pointer can be passed into the probe path and dereferenced by USB driver code, making kernel fault or crash realistic. * +1 Attacker-influenced lifetime manipulation: the relevant dynamic ID object is created and removed through the USB dynamic ID sysfs control path, and removal directly controls the lifetime transition that creates the stale reference. * +1 Structured stale-object exploitation leverage: the stale object is not a fixed DMA buffer or passive storage. It is a structured `usb_device_id` consumed by the driver matching/probe path, and driver callbacks may use its fields for active decisions. Negative signals: * -1 Conservative privilege/control-plane constraint: the complete trigger involves the USB dynamic ID `remove_id` sysfs path, which is a privileged driver-management interface in normal deployments. The supplied evidence does not fully resolve whether this is always host-admin-equivalent in all product contexts, so this is not treated as a proven -2 host-admin penalty. Paranoid difference: * The paranoid score does not apply the -1 privilege/control-plane reduction because delegated device-management services, reduced root contexts, or product-specific sysfs permissions may make the path reachable below full host administration. This does not prove unprivileged reachability, but it prevents automatic downgrade. Important non-awarded signals: * Controlled reclaim is not demonstrated. * Arbitrary kernel read or write is not demonstrated. * Callback or function-pointer control from reclaimed memory is not demonstrated. * Remote network reachability is not established. * No concrete repeated release/refcount mutation on the same dangling reference is shown. * Extra Availability was not awarded because the same likely kernel crash is already counted once. * Confidentiality and Integrity were not awarded as separate ActionableScore points because no concrete disclosure, overwrite, credential manipulation, or protected object modification is established. * Strong LPE leverage +2 was not awarded. The patch establishes a real UAF and meaningful unresolved structured stale-object use, but not controlled replacement or a demonstrated privilege escalation chain. Repeated release/refcount check: * First release can end lifetime: yes, `remove_id_store` can free the dynamic ID node. * Exact same reference survives: yes, old code returned a pointer to `dynid->id` after releasing `usb_dynids_lock`. * Second operation is a real lifetime/refcount mutation: no, the later vulnerable operation is stale structured-object use, not a second `put` or `free`. * Concrete repeated release/refcount +1 awarded: no. * Paranoid repeated-refcount leverage +1 awarded: no. * FLOOR 5 from repeated release/refcount applied: no. 3. Reachability analysis The trigger requires a race between USB interface probing and removal of a matching dynamic USB ID through the `remove_id` sysfs attribute. The attacker must be able to create or select a matching dynamic ID, initiate or wait for probing of a USB interface, and remove the dynamic ID while the probe path still uses the returned pointer. Ordinary unprivileged reachability is not established. The dynamic ID removal path is a sysfs driver-management interface and is normally restricted to privileged users. However, the supplied patch text does not fully prove that host-admin-equivalent privilege is required in every evaluated product or delegated management configuration, so `HostAdminRequired=UNKNOWN` is used rather than `YES`. Namespace-scoped privilege is not established. The relevant operation is USB driver dynamic ID management, not a namespace-local network object. There is no evidence that the complete trigger chain can be performed inside attacker-created user or network namespaces. Prior host setup may exist if a dynamic ID has already been added or if a management service exposes USB driver binding controls. Special rare hardware is not required in the scoring sense, because USB is common, but the vulnerable dynamic-ID workflow is a control-plane path and not ordinary packet or file input. The bug is a race, but no hard race penalty is applied. The two sides of the race are probe and sysfs removal, and a privileged or delegated actor may be able to retry the sequence. The evidence does not establish a one-shot, externally uncontrollable, or extremely narrow timing condition. 4. Primitive and severity interpretation The exact primitive is a use-after-free of a `usb_device_id` embedded in a dynamically allocated USB dynamic ID node. The old code returned a pointer into the protected list element, then released `usb_dynids_lock`. A concurrent `remove_id_store` can free that list node, leaving the probe path with a stale pointer. This is an active structured-object UAF rather than fixed stale storage. The stale object is passed into USB driver matching/probe logic and may be consumed by driver callbacks. It is not merely an async device write into a fixed buffer and not just a destructor-only stale dereference. No concrete repeated release/refcount operation exists. This is category A ordinary stale structured-object use, not category B second lifetime/refcount mutation through a potentially freed object. Primitive class is CLASS_B. The patch establishes a real kernel lifetime violation with structured stale use, but it does not establish CLASS_A evidence such as controlled reclaim, arbitrary write, callback hijack, credential overwrite, or demonstrated LPE. The demonstrated consequence is at least local denial of service through kernel crash or fault. The speculative consequence is broader exploitation from stale `usb_device_id` reuse, but the patch does not prove a useful reclaimed-object primitive. Because the stale object reaches driver probe logic rather than only immediate cleanup, the issue should not be automatically downgraded without manual review. ImportantCandidate is YES because this is a real active structured UAF in USB core with attacker-influenced object lifetime and unresolved post-free use in driver callbacks. AutoDowngradeAllowed is NO because automatic closure would discard a concrete kernel lifetime primitive whose exploitation leverage is not fully resolved. Likely operational severity is Actionable Moderate at minimum. It may become an Important candidate if product context shows below-host-admin reachability or if further analysis finds controlled reclaim, driver-specific sensitive use of `id->driver_info`, or another useful post-free consumption path. 5. One-sentence report phrase A USB core use-after-free can occur when dynamic ID removal races with interface probing, leaving `usb_probe_interface()` with a stale `usb_device_id` pointer that may be passed into driver probe callbacks and cause kernel crash or unresolved post-free structured-object use. 6. Manual review recommendation MANUAL CHECK REQUIRED Reason: the patch fixes a real UAF in a structured object passed across the USB core to driver callbacks. Controlled reclaim and LPE are not demonstrated, but the stale use is not limited to a fixed buffer or trivial cleanup fault, and product-specific reachability may materially change severity. 7. Call-site confidence Call-site confidence: high ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: usb: fix UAF when probe runs concurrent to dyn ID removal [ Upstream Commit: 9b82ddf76827e2a8ff033a8131ecf24f2d6cae26 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b82ddf76827e2a8ff033a8131ecf24f2d6cae26 Changed files: drivers/usb/core/driver.c include/linux/usb.h 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=9b82ddf76827e2a8ff033a8131ecf24f2d6cae26 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-93117 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93117 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:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H The Best / paranoid CVSS score: 7 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: 4 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: YES 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).