From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-93101][MODERATE 7.0] media: v4l2-async: Unregister sub-device if asc_list is empty [ Upstream Date: Fri, 18 Sep 2026 09:13:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-93101 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: 4 X-AL-KERNEL-ActionableScore-Lower: unknown X-AL-KERNEL-Commit: c7201bd08cad791858337e33ffcd90d8ae4147c2 List-Id: 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).