In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
Eliminate fetch_and_zero (Jani)
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)
Security readout for executives and security teams
Plain-English summary
A flaw in Linux’s Intel i915 graphics driver can leave hardware-monitoring data accessible after related memory is freed during device removal. A local, low-privileged user could potentially exploit this use-after-free to crash the system or compromise confidentiality and integrity. The supplied CVSS score is 7.8.
Executive priority
Treat as a high-priority local privilege boundary risk on affected multi-user systems using Intel i915 graphics. It is less urgent for isolated systems without untrusted local users, but remediation should follow the normal high-severity kernel update cycle. No supplied evidence supports emergency action for active exploitation.
Technical view
During i915 device unbind, separate cleanup paths may release hwmon driver data before unregistering hwmon. Access to the remaining hwmon sysfs interface can then dereference freed memory. The cited kernel changes replace device-managed cleanup with explicit release ordering. The supplied CWE-400 classification does not align clearly with the described use-after-free behavior.
Likely exposure
Exposure is limited to Linux systems using the Intel i915 driver and affected kernel builds. Exploitation requires local access with low privileges, no user interaction, and access during the device-unbind cleanup window. The bundle names versions 6.2, 6.6.34, 6.9.5, and 6.10, but does not provide unambiguous affected ranges.
Exploitation context
The supplied CVSS vector indicates local attack access, low complexity, low privileges, and potentially high confidentiality, integrity, and availability impact. The CVE is not listed as KEV, and the supplied sources provide no evidence of active exploitation or a public exploit.
Researcher notes
The vulnerable condition depends on cleanup ordering during i915 device unbind and later hwmon sysfs access. Source metadata is incomplete: affected-version boundaries are unclear, and the listed CWE-400 differs from the described memory-lifetime flaw. Confirm exposure through commit ancestry or distribution backport records rather than version strings alone.
Mitigation direction
Update to a vendor-supported kernel containing the applicable cited stable fix or backport.
Check distribution advisories to map packaged kernel versions to the cited commits.
Prioritize multi-user systems where untrusted users have local access.
Restrict unnecessary local access until affected systems are updated.
Validation and detection
Inventory Linux systems using the Intel i915 kernel driver.
Record running kernel and distribution package versions on those systems.
Verify whether the packaged kernel includes an applicable cited fix commit or vendor backport.
Review kernel logs for i915, hwmon, use-after-free, or memory-safety failures during device teardown.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-400: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
3Timeline events
2ADP providers
4Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-400 · source CWE mapping
Uncontrolled Resource Consumption
Uncontrolled Resource Consumption represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.