cbcvebase.
CVE-2023-53087
published 2025-05-02

CVE-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…

PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.20%
10.4th percentile
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_bar

Affected

17 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.25-1 (bookworm)linux 6.1.25-1 (bookworm)
linuxlinux——
linuxlinux>= 311770173fac27845a3a83e2c16100a54d308f72 < 5e784a7d07af42057c0576fb647b482f4cb0dc2c5e784a7d07af42057c0576fb647b482f4cb0dc2c
linuxlinux>= 311770173fac27845a3a83e2c16100a54d308f72 < 6ab7d33617559cced63d467928f478ea5c4590216ab7d33617559cced63d467928f478ea5c459021
linuxlinux>= 311770173fac27845a3a83e2c16100a54d308f72 < 5c7591b8574c52c56b3994c2fbef1a3a311b57155c7591b8574c52c56b3994c2fbef1a3a311b5715
linuxlinux>= 311770173fac27845a3a83e2c16100a54d308f72 < 9159db27fb19bbf1c91b5c9d5285e66cc96cc5ff9159db27fb19bbf1c91b5c9d5285e66cc96cc5ff
linuxlinux>= 311770173fac27845a3a83e2c16100a54d308f72 < e0e6b416b25ee14716f3549e0cbec1011b193809e0e6b416b25ee14716f3549e0cbec1011b193809
linuxlinux_kernel——
linuxlinux_kernel——
linuxlinux_kernel>= 0 < 5.10.178-15.10.178-1
linuxlinux_kernel>= 0 < 6.1.25-16.1.25-1
linuxlinux_kernel>= 0 < 6.1.25-16.1.25-1
linuxlinux_kernel>= 0 < 6.1.25-16.1.25-1
linuxlinux_kernel>= 5.11 < 5.15.1045.15.104
linuxlinux_kernel>= 5.16 < 6.1.216.1.21
linuxlinux_kernel>= 5.5 < 5.10.1765.10.176
linuxlinux_kernel>= 6.2 < 6.2.86.2.8

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.