CVE-2023-53087: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2023-53087

In the Linux kernel, the following vulnerability has been resolved: drm/i915/active: Fix misuse of non-idle barriers as fence trackers Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier. If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur. Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one. v3: use unlikely() to document what outcome we expect (Andi), - fix bad grammar in commit description. v2: no code changes, - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4, - reword commit description. (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7)

AI Analysis

Technical Summary

CVE-2023-53087 is a vulnerability in the Linux kernel's Direct Rendering Manager (DRM) subsystem, specifically within the i915 graphics driver responsible for Intel integrated graphics. The flaw arises from improper handling of fence trackers and barrier tasks in the drm/i915/active code path. The vulnerability is triggered when multiple graphics applications concurrently use the i915 performance monitoring (perf) interface, leading to race conditions in barrier processing. The root cause is a misuse of non-idle barriers as fence trackers, where the code attempts to delete a barrier from a list without properly checking the deletion's success. If deletion fails, the tracker remains incorrectly registered as a barrier task, causing list corruption and kernel oops (crashes). This occurs because the same data structure field is reused for fence callback lists and barrier task lists, and improper synchronization leads to concurrent modifications and corrupt linked lists. The issue was introduced after Linux kernel version 5.5 (commit 311770173fac) and relates to changes in scheduling request retirement when the timeline idles. The fix involves properly respecting the result of barrier deletion attempts, marking barriers as idle only upon successful deletion, and ensuring that non-idle barriers are not reused as trackers. This prevents list corruption and stabilizes concurrent operations on the i915 perf interface. The vulnerability does not currently have known exploits in the wild and affects Linux kernel versions containing the problematic commit. The flaw can cause system instability and crashes when using graphics-intensive workloads with concurrent perf monitoring, impacting reliability and availability of affected systems.

Potential Impact

For European organizations, this vulnerability primarily threatens the stability and availability of Linux systems running Intel integrated graphics with kernel versions affected by the flaw. Organizations relying on Linux servers or workstations for graphics-intensive applications, performance monitoring, or development environments could experience kernel crashes leading to service interruptions. This is particularly relevant for sectors such as media production, scientific computing, and software development where Intel graphics and Linux perf tools are used concurrently. While the vulnerability does not directly expose confidentiality or integrity risks, denial of service through kernel panics can disrupt critical operations. In environments with high concurrency of graphics workloads and performance monitoring, such as research institutions or cloud providers offering GPU-accelerated services, the impact could be more pronounced. The lack of known exploits reduces immediate risk, but unpatched systems remain vulnerable to stability issues. European organizations using Linux distributions that incorporate affected kernel versions should prioritize patching to maintain system reliability.

Mitigation Recommendations

European organizations should implement the following specific mitigations: 1) Identify Linux systems running affected kernel versions containing commit 311770173fac or later versions up to the patch release. 2) Apply the official Linux kernel patch that fixes the barrier deletion handling in the drm/i915 driver as soon as it becomes available from trusted sources or distribution vendors. 3) If immediate patching is not feasible, limit concurrent use of i915 perf monitoring tools with multiple graphics applications to reduce race conditions. 4) Monitor system logs for kernel oops or drm/i915 related errors indicative of this issue. 5) For critical production systems, consider temporarily disabling i915 perf features or using alternative performance monitoring tools that do not trigger the vulnerable code path. 6) Engage with Linux distribution maintainers to ensure timely backporting of the fix to Long Term Support (LTS) kernels commonly used in enterprise environments. 7) Educate system administrators and developers about the risk of concurrent graphics and perf workloads triggering kernel instability. These targeted steps go beyond generic advice by focusing on the specific driver, kernel commits, and operational practices that influence exploitability and impact.