CVE-2025-37754 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/huc: Fix fence not released on early probe errors
HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel:
<4> [309.731371] ------------[ cut here ]------------
<3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915]
<4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0
... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1
... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0
... <4> [309.731728] Call Trace:
<4> [309.731730] <TASK>
... <4> [309.731949] __debug_object_init+0x17b/0x1c0
<4> [309.731957] debug_object_init+0x34/0x50
<4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915]
<4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915]
<4> [309.732468] intel_uc_init_early+0x61/0x680 [i915]
<4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915]
<4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915]
<4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915]
<4> [309.733075] i915_pci_probe+0xe6/0x220 [i915]
<4> [309.733198] local_pci_probe+0x44/0xb0
<4> [309.733203] pci_device_probe+0xf4/0x270
<4> [309.733209] really_probe+0xee/0x3c0
<4> [309.733215] __driver_probe_device+0x8c/0x180
<4> [309.733219] driver_probe_device+0x24/0xd0
<4> [309.733223] __driver_attach+0x10f/0x220
<4> [309.733230] bus_for_each_dev+0x7d/0xe0
<4> [309.733236] driver_attach+0x1e/0x30
<4> [309.733239] bus_add_driver+0x151/0x290
<4> [309.733244] driver_register+0x5e/0x130
<4> [309.733247] __pci_register_driver+0x7d/0x90
<4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915]
<4> [309.733413] i915_init+0x34/0x120 [i915]
<4> [309.733655] do_one_initcall+0x62/0x3f0
<4> [309.733667] do_init_module+0x97/0x2a0
<4> [309.733671] load_module+0x25ff/0x2890
<4> [309.733688] init_module_from_file+0x97/0xe0
<4> [309.733701] idempotent_init_module+0x118/0x330
<4> [309.733711] __x64_sys_finit_module+0x77/0x100
<4> [309.733715] x64_sys_call+0x1f37/0x2650
<4> [309.733719] do_syscall_64+0x91/0x180
<4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e
<4> [309.733792] </TASK>
... <4> [309.733806] ---[ end trace 0000000000000000 ]---
That scenario is most easily reproducible with igt@i915_module_load@reload-with-fault-injection.
Fix the issue by moving the cleanup step to driver release path.
(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability described in CVE-2025-37754 resides within the Linux kernel's Intel i915 graphics driver, specifically in the handling of HuC (Hardware Unified Code) delayed loading fences. This issue manifests as a kernel warning and taints the kernel due to improper cleanup of a software fence object during early driver probe failures. The root cause stems from a design flaw where the HuC fence is registered with the object tracker early in the driver initialization process but is only unregistered during the driver removal phase. When early probe errors occur, the driver removal path is never executed, leaving the fence in an inconsistent state. The fence object, allocated via the device resource management system, gets reused in subsequent driver probe attempts, leading to a debug object initialization error. This behavior is categorized under CWE-691, which deals with insufficient control flow management, and can be linked to ATT&CK technique T1059.006 for privilege escalation through kernel module manipulation. The vulnerability is particularly concerning because it can lead to kernel instability and tainting, which may mask other underlying issues and reduce system reliability.
The technical flaw involves a mismanagement of kernel object lifecycle within the i915 driver's early initialization sequence. The HuC delayed loading fence was introduced to track the status of HuC loading operations but was not properly integrated into the error handling path. The fence object is initialized through `__i915_sw_fence_init` and registered with the object tracker during `intel_huc_init_early`, which is called early in the driver probe process. However, when an early probe error occurs, the driver fails to reach the cleanup phase where the fence would normally be unregistered, leading to a dangling reference. The call trace shows that the error originates from `debug_object_init` which is invoked by `__i915_sw_fence_init`, indicating that the system attempts to reinitialize an already initialized object, causing a kernel warning. This improper state management creates a scenario where the fence object's memory is reallocated and reused, triggering the ODEBUG warning and ultimately resulting in kernel taint. The specific commit 27536e03271da introduced the fence tracking mechanism, but did not account for early termination scenarios during driver probe, which is a classic example of incomplete resource management and violates the principle of proper object lifecycle handling in kernel space.
The operational impact of this vulnerability is significant in environments where graphics drivers undergo frequent reloads or where fault injection testing is performed, as indicated by the reproduction method using igti915_module_loadreload-with-fault-injection. When the system experiences early probe errors, which can occur due to hardware incompatibilities, driver version mismatches, or test scenarios, the kernel becomes tainted, potentially masking other security issues or stability problems. This taint can prevent certain security features from functioning correctly and may cause the system to behave unpredictably under stress conditions. In production environments, this vulnerability could lead to intermittent system instability, particularly during driver loading phases, and might be exploited by attackers to create denial-of-service conditions or to hide malicious activities within the kernel. The vulnerability is especially problematic in virtualized environments or systems where driver reloads are common, as it can cause cascading failures and complicate debugging efforts.
The mitigation strategy for this vulnerability involves implementing a proper cleanup mechanism that ensures the HuC fence is unregistered regardless of whether the driver probe completes successfully or fails early. The fix, as implemented in commit 795dbde92fe5c6996a02a5b579481de73035e7bf, moves the fence cleanup step to the driver release path, ensuring that even in early probe error scenarios, the fence object is properly released. This approach aligns with the principle of defensive programming and proper resource management in kernel space, ensuring that all allocated resources are freed appropriately during the driver lifecycle. System administrators should ensure that affected systems are updated with the patched kernel version to prevent the occurrence of these kernel warnings and maintain system stability. The fix also emphasizes the importance of thorough testing of driver initialization paths, particularly under error conditions, to prevent similar issues from occurring in other kernel subsystems. Additionally, monitoring for kernel taint warnings can serve as an early indicator of potential issues related to improper resource management in kernel modules.