CVE-2025-23162 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vf: Don't try to trigger a full GT reset if VF
VFs don't have access to the GDRST(0x941c) register that driver uses to reset a GT. Attempt to trigger a reset using debugfs:
$ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset
or due to a hang condition detected by the driver leads to:
[ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe]
[ ] xe 0000:00:02.1: [drm] GT0: reset queued
[ ] xe 0000:00:02.1: [drm] GT0: reset started
[ ] ------------[ cut here ]------------
[ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0
[ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
[ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
[ ] Call Trace:
[ ] <TASK>
[ ] ? show_regs+0x6c/0x80
[ ] ? __warn+0x93/0x1c0
[ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
[ ] ? report_bug+0x182/0x1b0
[ ] ? handle_bug+0x6e/0xb0
[ ] ? exc_invalid_op+0x18/0x80
[ ] ? asm_exc_invalid_op+0x1b/0x20
[ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
[ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]
[ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe]
[ ] ? __mutex_unlock_slowpath+0x41/0x2e0
[ ] xe_mmio_write32+0x64/0x150 [xe]
[ ] do_gt_reset+0x2f/0xa0 [xe]
[ ] gt_reset_worker+0x14e/0x1e0 [xe]
[ ] process_one_work+0x21c/0x740
[ ] worker_thread+0x1db/0x3c0
Fix that by sending H2G VF_RESET(0x5507) action instead.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/07/2025
The vulnerability described in CVE-2025-23162 affects the Linux kernel's graphics driver subsystem, specifically within the Intel xeon edgewater (xe) driver implementation. This issue manifests in virtual function (VF) environments where the driver attempts to execute a full graphics translation reset operation on a graphics translation unit that lacks proper access permissions. The root cause stems from the driver's attempt to write to the GDRST register at address 0x941c, a register that virtual functions do not have access to in virtualized environments. This represents a clear violation of privilege separation principles and demonstrates a failure in access control enforcement within the kernel's graphics driver framework. The vulnerability is particularly concerning because it occurs during system recovery operations, specifically when attempting to reset a graphics translation unit after detecting a hang condition or when manually triggering a reset through debugfs interfaces.
The technical flaw occurs within the xe_gt_sriov_vf.c source file at line 996 where the xe_gt_sriov_vf_write32 function attempts to write to an inaccessible register. This function is part of the virtual function implementation that handles graphics reset operations for virtualized graphics environments. The error message indicates that the VF is attempting to write value 0x1 to register 0x941c, which triggers a kernel warning and eventually results in a kernel oops or system crash. The call stack shows that this operation originates from the gt_reset_worker function which is responsible for managing reset operations in response to hang conditions or manual triggers. This behavior represents a classic case of privilege escalation attempt or access violation that can lead to system instability and potential denial of service conditions. The vulnerability directly maps to CWE-284 (Improper Access Control) and CWE-787 (Out-of-bounds Write) as it involves unauthorized access to restricted system resources and subsequent memory corruption.
The operational impact of this vulnerability is significant in virtualized graphics environments where multiple virtual machines share the same physical graphics hardware through SR-IOV (Single Root I/O Virtualization) implementations. When a VF attempts to trigger a graphics reset operation, the system experiences a kernel panic or system crash, effectively rendering the graphics subsystem unusable for that particular virtual function. This can lead to complete system instability, especially in server environments where graphics processing is critical for virtual desktop infrastructure or high-performance computing workloads. The vulnerability affects systems using Intel graphics hardware in virtualized environments and can be exploited by malicious virtual functions to cause denial of service conditions, potentially disrupting legitimate users and applications that depend on graphics processing capabilities. The issue is particularly problematic because it occurs during system recovery operations, which are meant to restore functionality rather than introduce instability, indicating a fundamental flaw in the driver's error handling and privilege management.
The mitigation strategy for this vulnerability involves implementing proper access control checks before attempting reset operations in virtual function environments. The fix requires modifying the driver code to detect when a VF is attempting to perform a reset operation and instead send a VF_RESET action (0x5507) through the host-to-guest communication mechanism rather than attempting direct register access. This approach aligns with the principle of least privilege and ensures that virtual functions can request reset operations through proper communication channels established by the hypervisor. The solution demonstrates a proper implementation of the ATT&CK technique T1490 (Inhibit System Recovery) through defensive programming practices that prevent unauthorized access to restricted system resources. Organizations should ensure that all graphics drivers in virtualized environments are updated to versions containing this fix, particularly in enterprise deployments where graphics virtualization is utilized. System administrators should also monitor for kernel oops messages and system crashes related to graphics reset operations, as these may indicate the presence of this vulnerability in unpatched systems. The fix represents a fundamental improvement in the driver's handling of virtualized graphics environments and demonstrates proper adherence to virtualization security best practices.