[CVE-2026-80952][MODERATE 7.0] i3c: master: Fix info leak and UAF in device unregister path

[CVE-2026-80952][MODERATE 7.0] i3c: master: Fix info leak and UAF in device unregister path

[AL-KERNEL]

CVE: CVE-2026-80952
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: i3c: master: Fix info leak and UAF in device unregister path
Commit: c16b6f25e0cc2dd1055dde1256cbf5a9e888cf49
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c16b6f25e0cc2dd1055dde1256cbf5a9e888cf49
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80952
Analysis date: Fri, 11 Sep 2026 20:17:15 -0400
ActionableScore: 5
ActionableScore lower bound: unknown
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-80952 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-80952

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-80952	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-80952 CHECK WITH IMPACT FROM ORIG NN LOW	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-200;*CWE-457;*CWE-416;CWE-362;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L';BEST CVSS score: '7';DESCR 'An information leak in the I3C device unregister path can occur because i3cdev dev desc is cleared before device_unregister() completes. During device_unregister(), KOBJ_REMOVE uevent generation and driver unbind can still call paths such as i3c_device_uevent() or a racing modalias_show(), which expect desc to remain valid. If desc is NULL, the code can fall back to an uninitialized stack i3c_device_info and expose kernel stack bytes through the generated modalias. The same lifetime window can also affect driver remove callbacks and is treated as a potential UAF candidate because the unregister path can drop the device reference while code still reasons about the device descriptor. For the CVSS the PR:L value is used in the paranoid score because a local unprivileged process may be able to observe uevents or race sysfs modalias access on the same system, although reliable triggering of device unregister usually depends on local device or driver control. The issue is not network reachable. Impact is at least local information disclosure and possible denial of service. In the paranoid interpretation, memory lifetime risk justifies manual review for possible confidentiality, integrity, and availability impact.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5)	YES	INIT LEAK UAF HARDWARE  KPANIC INCREASED_TO_MODERATE7_FROM_LOW_BASED_ON_GUESSCVSS_AND_ACTIONABLESCOREHIGHER4	YES	NO	checked

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

ActionableScore=5
PrimitiveClass=CLASS_B
RealUAF=YES
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 3
* Conservative score: 5
* Raw paranoid score: 4
* Paranoid score: 5
* Applied conservative floor: 3 -> 5 because the patch establishes a real lifetime/UAF hazard plus a user-visible kernel stack disclosure path.
* Applied paranoid floor: 4 -> 5 for the same reason. No higher paranoid score is used because controlled reclaim, arbitrary write, or demonstrated LPE is not established.
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

2. Signal breakdown

Conservative signals:

* +2 Real UAF / lifetime violation. The unregister path interacts with device_unregister(), which drops the device reference and may free the device. The fix takes get_device() before unregistering and clears desc only after device_unregister() completes.
* +1 Confidentiality plausible. i3c_device_uevent() or racing modalias_show() can observe desc == NULL and use an uninitialized stack struct i3c_device_info, leaking kernel stack contents through modalias output.
* +0 Reliable kernel crash / strong DoS not awarded conservatively. Driver remove callbacks may see unexpected NULL desc, but a concrete crash path is not shown.
* +0 Local unprivileged trigger not awarded. A local user may be able to observe uevents or read sysfs modalias, but the complete ability to trigger I3C device unregister below host-admin privilege is not established.
* +0 Strong LPE / strong exploitation leverage not awarded. No controlled reclaim, attacker-shaped replacement object, arbitrary write, callback hijack, or demonstrated privilege escalation is shown.

Paranoid additional signal:

* +1 Weak unresolved lifetime concern. The same unregister window affects uevent generation, modalias access, and driver remove callbacks while desc is expected to remain valid, so post-lifetime or invalid lifetime-state handling needs manual review.

Important non-awarded signals:

* Controlled reclaim not demonstrated.
* Arbitrary or directed kernel write not demonstrated.
* Remote reachability not established.
* Concrete repeated release/refcount mutation on the same dangling reference is not established.
* Structured stale-object leverage is not separately awarded because attacker-controlled replacement or meaningful post-reuse field consumption is not shown.
* Extra Availability is not awarded because a concrete crash or persistent host-wide DoS is not demonstrated.
* C/I are not raised beyond the demonstrated stack disclosure merely because UAF could theoretically corrupt reclaimed memory.

Repeated-release/refcount checklist:

* First release can end lifetime: device_unregister() can drop the device reference and may free the device.
* Exact same reference survives into a second lifetime-mutating operation: not established as a repeated put/free on the same dangling reference in the vulnerable old code.
* Second operation is a real lifetime/refcount mutation: not established.
* +1 Concrete repeated release/refcount awarded: no.
* Paranoid repeated-refcount leverage +1 awarded: no.
* FLOOR 5 applied: yes, but due to real lifetime hazard plus stack disclosure, not due to repeated release/refcount.

3. Reachability analysis

The directly affected path is I3C device unregister. Reliable triggering appears tied to device unregister or master teardown, which often depends on driver or device-management control, but the supplied evidence does not positively prove host-admin-equivalent privilege is required for every complete trigger path. Therefore HostAdminRequired is UNKNOWN, not YES.

A local unprivileged process may be able to observe KOBJ_REMOVE uevents or race sysfs modalias_show(), but observing the leak is not the same as proving complete below-host-admin trigger control over unregister. No network trigger is indicated. No namespace-scoped capability path is indicated, so NamespaceScopedPrivilege is NO.

No prior host setup beyond having I3C devices and the driver present is proven as a separate attacker-controlled prerequisite. I3C is hardware-dependent, but the prompt does not establish rare or physical-only attacker requirements sufficient for a reducing hardware penalty. Race repeatability is unresolved. The modalias_show() path is a race, while the KOBJ_REMOVE uevent path is naturally part of unregister.

4. Primitive and severity interpretation

The exact primitive is a kernel stack information disclosure caused by clearing i3cdev->dev->desc before device_unregister() finishes, allowing modalias generation to fall back to uninitialized stack data. The patch also establishes a real device lifetime hazard because device_unregister() may drop the final device reference, requiring get_device() before the descriptor is cleared after unregister.

This is an active structured device-object lifetime issue, not fixed stale DMA storage. The demonstrated consequence is local information disclosure of kernel stack bytes. Potential consequences include driver remove callback failure or UAF-related corruption, but controlled reclaim, arbitrary read/write, callback control, and privilege escalation are not demonstrated.

PrimitiveClass is CLASS_B because a real lifetime/UAF hazard is established and exploitation-leverage analysis is required. ImportantCandidate is YES because kernel stack disclosure plus unresolved device lifetime handling should not be automatically downgraded. AutoDowngradeAllowed is NO because automatic closure would discard a concrete information leak and unresolved lifetime primitive.

Likely operational severity is actionable Moderate, with Strong Important review needed only if follow-up analysis shows attacker-controlled unregister, useful stack disclosure content, controlled reuse, or a concrete crash/LPE path.

5. One-sentence report phrase

An I3C unregister ordering bug can expose kernel stack bytes through modalias generation and leaves an unresolved device lifetime hazard because desc is cleared before device_unregister() completes while unregister may drop the final device reference.

6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: the issue includes a concrete kernel stack information leak and a directly indicated device lifetime/UAF hazard, while attacker reachability and exploitation leverage beyond disclosure remain unresolved.

7. Call-site confidence

Call-site confidence: medium

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

Patch: i3c: master: Fix info leak and UAF in device unregister path
Commit: c16b6f25e0cc2dd1055dde1256cbf5a9e888cf49
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c16b6f25e0cc2dd1055dde1256cbf5a9e888cf49

Commit description:

i3c_master_unregister_i3c_devs() clears i3cdev->dev->desc before
calling device_unregister().  During device_unregister(),
device_del() emits a KOBJ_REMOVE uevent and unbinds the driver while
the device descriptor is still expected to be valid.  As a result,
i3c_device_uevent() and a racing modalias_show() can observe a NULL
desc and fall back to an uninitialized stack struct i3c_device_info,
leaking kernel stack contents in the generated modalias.  Driver
.remove() callbacks may also encounter an unexpected NULL desc during
unbind.

Keep desc valid until device_unregister() has completed.  Since
device_unregister() drops the device reference and may free the device,
take an extra reference with get_device() before unregistering.  Clear
desc afterwards and release the extra reference with put_device().
This preserves the release-time invariant that desc must be NULL while
avoiding both the information leak and a potential use-after-free from
writing desc after the device has been released.

Reported-by: sashiko-bot@kernel.org
Link: https://lore.kernel.org/linux-i3c/20260702190003.8BF741F000E9@smtp.kernel.org/
Fixes: 3a379bb ("i3c: Add core I3C infrastructure")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260723075747.34049-1-adrian.hunter@intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  drivers/i3c/master.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=c16b6f25e0cc2dd1055dde1256cbf5a9e888cf49

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

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

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:L/UI:N/S:U/C:L/I:N/A:L
  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: unknown
  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).