Douglas Anderson

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to the drm/msm/a6xx component of the Linux kernel, where a slab-out-of-bounds error occurs due to insufficient memory allocation for the GMU registers array. This happens when the `a6xx get gmu registers()` function reads 3 sets of registers, but the memory allocation was not updated accordingly. The error leads to a KASAN warning and can cause a denial of service. The vulnerable function is `(a6xx get gmu registers())`, and the affected component is the `drm/msm/a6xx` subsystem. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a component of the Linux kernel, specifically drm/msm/devfreq, and is caused by a lack of memory release after its effective lifetime. Exploitation of this issue could allow an attacker to cause a denial of service. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

The vulnerability is related to a classic ABBA deadlock in the Linux kernel's clk component. It occurs when a thread is walking the clk tree and calling `clk pm runtime get()` to power on devices required to read the clk hardware, while another thread is runtime PM resuming the same device, causing a deadlock. The issue is caused by the `clk prepare lock` being held while trying to runtime PM resume or suspend a device. This can lead to a denial-of-service (DoS) condition.

The issue is related to the initialization of the `ddp comp` array in the Linux kernel's drm/mediatek module. When `conn routes` is true, an extra slot is allocated in the array, but it is not initialized by `mtk drm crtc create()`. This can cause a crash when looping through the array in `mtk drm crtc mode valid()`. The problem is more likely to occur when the memory is poisoned, such as when booting with `slub debug=FZPUA`. Initializing the array with `devm kcalloc()` can prevent the crash, as it sets the memory to zero. This is considered a safer practice, especially when the array is small.

The issue is related to a NULL pointer dereference in the `i2c hid of probe()` function in the Linux kernel's HID device driver for I2C. This occurs when the I2C HID implementation is split into ACPI and OF parts, but the new OF driver fails to initialize the client pointer, which is then dereferenced on power-up failures. This could allow an attacker to cause a denial of service.