[CVE-2026-93101][MODERATE 7.0] media: v4l2-async: Unregister sub-device if asc_list is empty [ Upstream

[CVE-2026-93101][MODERATE 7.0] media: v4l2-async: Unregister sub-device if asc_list is empty [ Upstream

[AL-KERNEL]

CVE: CVE-2026-93101
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: media: v4l2-async: Unregister sub-device if asc_list is empty [ Upstream
Commit: c7201bd08cad791858337e33ffcd90d8ae4147c2
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c7201bd08cad791858337e33ffcd90d8ae4147c2
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93101
Analysis date: Fri, 18 Sep 2026 09:13:33 -0400
ActionableScore: 4
ActionableScore lower bound: unknown
Actionable bucket: Borderline / manual review recommended
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-93101 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93101

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-93101	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-93101 CHECK WITH IMPACT FROM ORIG NN MODERATE	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H';*CWE-416;*CWE-672;CWE-703;Other CVSS 'AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '5.7';DESCR 'A V4L2 sub-device can remain registered when v4l2_async_unregister_subdev() sees an empty asc_list, even though the underlying USB media device is being disconnected. This can leave stale registration state after the i2c sub-device is torn down and can lead to a kernel crash when V4L2 core or the bridge driver later touches that state. For the CVSS the PR:N is used for the paranoid physical scenario because unplugging an already attached affected USB device does not require an OS account. The issue is not network reachable and normally requires physical access to a specific affected media device and driver combination. Impact is at least denial of service via kernel crash. In worst case it is a stale object lifetime bug and may deserve limited confidentiality or integrity consideration as a UAF candidate, so manual review is recommended.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 4)  SKIP CVE-2026-93101 UNKNOWN SKIP The Fixes patch not applied yet, so unlikely that actual: url YES  NO NO unknown 	MAYBE	DANGER INIT SIMPLEFIX HARDWARE KPANIC 	-	-	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=4
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=YES

1. ActionableScore

* Raw conservative score: 1
* Conservative score: 4
* Raw paranoid score: 1
* Paranoid score: 4
* Applied conservative floor/cap: Real UAF / stale registration floor 1 -> 4
* Applied paranoid floor/cap: Real UAF / stale registration floor 1 -> 4
* Final recommended bucket: **Borderline / manual review recommended**::

2. Signal breakdown

Positive signals:

* +2 Real UAF / lifetime violation: the sub-device may remain registered after the underlying USB/I2C media device is disconnected and torn down, leaving stale V4L2 registration state.
* +1 Reliable kernel crash / strong DoS: the commit explicitly says the affected em28xx plus tvp5150 disconnect path crashes.

Negative signals:

* -2 Physical-only / specific hardware path: the demonstrated trigger requires disconnecting a specific affected USB media device and driver combination. This is not network reachable and not a broad software-only attack surface.

Non-awarded signals:

* Controlled reclaim not demonstrated.
* Arbitrary or directed kernel write not demonstrated.
* Confidentiality and integrity impact not awarded because no disclosure path, attacker-controlled replacement object, callback hijack, or protected-state modification is established.
* Structured stale-object leverage not awarded because the stale use is demonstrated as disconnect/unregister cleanup leading to crash, not as attacker-shaped post-free structured reuse.
* Weak LPE not awarded merely because this is a UAF-like stale lifetime bug.
* Concrete repeated release/refcount signal not awarded. The patch does not show first put/free followed by a second lifetime-mutating put/free on the exact same dangling reference.
* Extra Availability point not awarded because the same crash is already counted.
* Remote reachability not established.

Repeated-release/refcount checklist:

* First release can end lifetime: not shown in the supplied patch.
* Exact same reference survives to second lifetime mutation: not shown.
* Second operation is a real lifetime/refcount mutation: not shown.
* +1 Concrete repeated release/refcount awarded: no.
* Paranoid repeated-refcount leverage +1 awarded: no.
* FLOOR 5 applied: no.

3. Reachability analysis

The demonstrated trigger is physical/local: disconnecting an affected USB media device using the em28xx bridge with an I2C tvp5150 sub-device. No host administrator privilege is needed to physically unplug an already attached device, so HostAdminRequired=NO for the demonstrated physical scenario.

There is no network path. There is no namespace-scoped privilege question in the supplied evidence, so NamespaceScopedPrivilege=NO. The attacker cannot be assumed to instantiate the complete vulnerable device stack remotely. Prior setup requires the vulnerable hardware and driver combination to be present, but the actual crash trigger is device disconnect.

No race or narrow timing requirement is established. The issue is a deterministic unregister/lifetime corner case when sd->asc_list is empty.

4. Primitive and severity interpretation

The exact primitive is stale V4L2 sub-device registration after the backing device is disconnected. This is best treated as a constrained Class B lifetime/UAF-style bug rather than Class C because a kernel object remains externally registered past the lifetime assumptions of the device stack.

The stale object is an active structured V4L2 sub-device registration, not merely a passive integer or diagnostic flag. However, the supplied evidence shows a crash on disconnect/unregister behavior, not controlled post-free reuse, attacker-shaped object replacement, arbitrary read/write, callback control, or privilege escalation.

This is closer to:

A. ordinary stale cleanup or unregister lifetime bug causing crash

than:

B. second lifetime/refcount mutation through a potentially dangling object.

PrimitiveClass=CLASS_B is appropriate. ImportantCandidate=NO because the bug is constrained to a physical/specific-device crash path and lacks meaningful unresolved exploitation leverage beyond stale registration. AutoDowngradeAllowed=YES because the demonstrated consequence is crash-only, no repeated lifetime/refcount mutation is established, and no security-boundary or controlled corruption primitive is shown.

Likely operational severity is borderline Moderate: worth manual review due to the stale lifetime nature, but not an Important-class candidate from the supplied evidence alone.

5. One-sentence report phrase

A V4L2 sub-device registered outside v4l2-async may remain registered when asc_list is empty during USB media device disconnect, leaving stale registration state and causing a kernel crash, but no network vector, controlled reclaim, or privilege escalation primitive is established.

6. Manual review recommendation

MANUAL CHECK RECOMMENDED

Reason: this is a real stale lifetime / UAF-candidate driver bug, but the evidence supports a constrained physical crash-only path with no demonstrated exploitation leverage beyond DoS.

7. Call-site confidence

Call-site confidence: medium

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: media: v4l2-async: Unregister sub-device if asc_list is empty [ Upstream
Commit: c7201bd08cad791858337e33ffcd90d8ae4147c2
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c7201bd08cad791858337e33ffcd90d8ae4147c2

Changed files:
  drivers/media/v4l2-core/v4l2-async.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=c7201bd08cad791858337e33ffcd90d8ae4147c2

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-93101 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-93101

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:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS vector: AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS score: 5.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: unknown
  Paranoid ActionableScore: 4

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).