From: AL-KERNEL <[email protected]>
To: [email protected]
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 [thread overview]
Message-ID: <[email protected]> (raw)
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 [email protected] (and both
send reply to CVE record itself too and see "reply" button below for howto reply).
reply other threads:[~2026-09-18 2:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --from, and --in-reply-to
switches of git-send-email(1) and next cmd tested by kernelcve.org admin:
git send-email --smtp-server=mail.kernelcve.org --smtp-server-port=25 --smtp-auth=none --from='Your Name <youremail@domain.is>' --suppress-cc=all --no-cc \
--in-reply-to=cve-2026-93117.056cab96081cca177d53acb7@kernelcve.org \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
The file with msg could look like this then:
cat YOUR_REPLY
Subject: Re: [CVE-2026-64206][MODERATE REGULAR] Bluetooth: L2CAP test
Just testing public-inbox replies.
Thanks,
MyName
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox