CVE-2023-54202

What it actually does

Use-after-free in i915_perf_add_config_ioctl due to racing oa_config object creation against removal, with dereference occurring after metrics_lock release.

Why it matters to the business

Affected Linux systems using i915 graphics hardware face kernel instability or potential code execution; low EPSS and absence from KEV indicate minimal observed exploitation despite 300+ days since publication.

How an attack unfolds

An attacker with userspace access guesses a valid config ID and concurrently invokes add and remove paths through the perf ioctl, winning the race to free the object while another thread still holds a reference after unlocking metrics_lock.

How to fix it

Upgrade the Linux kernel to a version containing commit 6eeb1cba4c9dc47656ea328afa34953c28783d8c; apply the equivalent stable patch for the running branch.

How to confirm the fix worked

Confirm the running kernel source contains the reordered unlock after object dereference in i915_perf_add_config_ioctl or verify presence of the fix commit in git history.

Typical attack path

1. Locate system with i915 GPU and perf metrics enabled
2. Guess or brute-force a valid oa_config ID
3. Trigger concurrent i915_perf_add_config_ioctl and removal calls
4. Force dereference of freed object post-lock release

How to detect it

Review kernel logs and dmesg for use-after-free oops involving drm/i915 or i915_perf; correlate with processes issuing perf config ioctls around crash timestamps.

What your security team should do

• Prioritize kernel updates on systems exposing i915 perf interfaces
• Audit custom i915 perf configurations for unnecessary exposure
• Enable kernel hardening features such as KASAN in test environments to catch similar UAFs