Matthew Auld

An out-of-bounds kernel read can occur in the `drm/xe` component when a user provides an invalid `pat index` value through the `madvise` IOCTL. This happens because the `madvise args are sane()` function calls `xe pat index get coh mode()` without verifying if the `pat index` is within the valid range of the `xe->pat.table` array. While debug builds include a warning, production kernels still perform the unsafe array access.

The issue is related to a use-after-free (UAF) vulnerability in the `send recv()` function, specifically in the `drm/xe/ct` module of the Linux kernel. This vulnerability can be exploited to impact the confidentiality, integrity, and availability of protected information. The vulnerability arises due to the lack of proper synchronization with the completion side, which can lead to a fence going out of scope on the stack before the timeout. Additionally, there are dependent loads and stores that require correct ordering, but the necessary barriers are lacking. The fix involves grabbing the `ct->lock` after the wait to ensure proper serialization.

The issue is related to a use-after-free vulnerability in the Linux kernel, specifically in the drm/xe module. This vulnerability can be exploited to impact the confidentiality, integrity, and availability of protected information. The vulnerability is caused by the improper teardown of the driver instance, leading to various use-after-free errors. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to the `xe vm create ioctl()` function in the `drivers/gpu/drm/xe/xe vm.c` module of the Linux kernel, which is associated with the reuse of previously freed memory. An attacker can exploit this by guessing the next ID of the VM before the ioctl completes and then calling the VM destroy ioctl to trigger the reuse of the freed memory, as the create ioctl is still referencing the same VM. The fix involves moving the `xa alloc` to the end to prevent this. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

A real deadlock as well as a sleeping in atomic bug has been identified in the Linux kernel, specifically in the drm/xe/client module. The issue arises when the bo put happens to be the last ref, causing bo destruction to attempt to grab the same spinlock and sleeping locks. This is resolved by dropping the ref using `xe bo put deferred()` and moving the final commit outside of the lock. The process of dropping the lock around the put is complex due to the potential for the bo to go out of scope and delete itself from the list, making navigation to the next list entry challenging.

The issue is related to a use-after-free (UAF) vulnerability in the Linux kernel, specifically in the drm/xe module. The vulnerability occurs when the fence lock is part of the queue, and anything locking the fence should also hold a reference to the queue to prevent it from being freed. However, the current design signals the fence and then drops the queue reference, which can lead to a situation where the lock is freed as part of the queue, resulting in a UAF. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. To prevent this, the fence lock can be moved into the fence itself to avoid lifetime issues. Alternative solutions might include having a device-level lock or only releasing the queue in the fence release callback, although this might require pushing to another worker to avoid locking issues.

The issue is related to the `drm/buddy` component of the Linux kernel, specifically with the `alloc range()` function. This function was returning `SUCCESS` in certain corner cases when it couldn't find the required memory blocks, leading to display corruption when booting to KDE Plasma or playing games. The correct approach is for the function to return `-ENOSPC` when the total allocated size is less than the required size.