发布时间: 2024年8月16日
修改时间: 2024年8月30日
In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Fix potential UAF by revoke of fence registersCI has been sporadically reporting the following issue triggered byigt@i915_selftest@live@hangcheck on ADL-P and similar machines:<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence...<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled<3> [414.070354] Unable to pin Y-tiled fence; err:-4<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))...<4>[ 609.603992] ------------[ cut here ]------------<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]...<4>[ 609.604271] Call Trace:<4>[ 609.604273] <TASK>...<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]<4>[ 609.604977] force_unbind+0x24/0xa0 [i915]<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]<4>[ 609.605440] process_scheduled_works+0x351/0x690...In the past, there were similar failures reported by CI from other IGTtests, observed on other platforms.Before commit 63baf4f3d587 ( drm/i915/gt: Only wait for GPU activitybefore unbinding a GGTT fence ), i915_vma_revoke_fence() was waiting foridleness of vma->active via fence_update(). That commit introducedvma->fence->active in order for the fence_update() to be able to waitselectively on that one instead of vma->active since only idleness offence registers was needed. But then, another commit 0d86ee35097a( drm/i915/gt: Make fence revocation unequivocal ) replaced the call tofence_update() in i915_vma_revoke_fence() with only fence_write(), andalso added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.No justification was provided on why we might then expect idleness ofvma->fence->active without first waiting on it.The issue can be potentially caused by a race among revocation of fenceregisters on one side and sequential execution of signal callbacks invokedon completion of a request that was using them on the other, stillprocessed in parallel to revocation of those fence registers. Fix it bywaiting for idleness of vma->fence->active in i915_vma_revoke_fence().(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)
| NVD | openEuler | |
|---|---|---|
| CVSS评分 | 7.8 | 7.8 |
| Attack Vector | Local | Local |
| Attack Complexity | Low | Low |
| Privileges Required | Low | Low |
| User Interaction | None | None |
| Scope | Unchanged | Unchanged |
| Confidentiality | High | High |
| Integrity | High | High |
| Availability | High | High |
| 公告名 | 概要 | 发布时间 |
|---|---|---|
| KylinSec-SA-2024-3561 | kernel security update | 2024年8月16日 |
| 产品 | 包 | 状态 |
|---|---|---|
| KY3.4-5A | kernel | Unaffected |
| KY3.5.2 | kernel | Fixed |
| V6 | kernel | Fixed |
