CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26647 – drm/amd/display: Fix late derefrence 'dsc' check in 'link_set_dsc_pps_packet()'
https://notcve.org/view.php?id=CVE-2024-26647
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix late derefrence 'dsc' check in 'link_set_dsc_pps_packet()' In link_set_dsc_pps_packet(), 'struct display_stream_compressor *dsc' was dereferenced in a DC_LOGGER_INIT(dsc->ctx->logger); before the 'dsc' NULL pointer check. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:905 link_set_dsc_pps_packet() warn: variable dereferenced before check 'dsc' (see line 903) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: se corrigió la verificación de desrefrence tardía 'dsc' en 'link_set_dsc_pps_packet()'. En link_set_dsc_pps_packet(), se eliminó la referencia a 'struct display_stream_compressor *dsc' en un DC_LOGGER_INIT(dsc- >ctx->registrador); antes de la verificación del puntero NULL 'dsc'. Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:905 link_set_dsc_pps_packet() advertencia: variable desreferenciada antes de verificar 'dsc' (consulte la línea 903) • https://git.kernel.org/stable/c/6aa5ede6665122f4c8abce3c6eba06b49e54d25c https://git.kernel.org/stable/c/cf656fc7276e5b3709a81bc9d9639459be2b2647 https://git.kernel.org/stable/c/3bb9b1f958c3d986ed90a3ff009f1e77e9553207 •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26646 – thermal: intel: hfi: Add syscore callbacks for system-wide PM
https://notcve.org/view.php?id=CVE-2024-26646
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). • https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566 https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9 https://access.redhat.com/security/cve/CVE-2024-26646 https://bugzilla.redhat.com/show_bug.cgi?id=2271788 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52627 – iio: adc: ad7091r: Allow users to configure device events
https://notcve.org/view.php?id=CVE-2023-52627
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7091r: Allow users to configure device events AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set. Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation. Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: adc: ad7091r: permitir a los usuarios configurar eventos de dispositivo Los dispositivos AD7091R-5 son compatibles con el controlador ad7091r-5 junto con el controlador ad7091r-base. Esos controladores declararon eventos iio para notificar al espacio del usuario cuando las lecturas de ADC caen por debajo de los umbrales de los registros de límite bajo o por encima de los valores establecidos en los registros de límite alto. Sin embargo, para configurar los eventos de iio y sus umbrales, se debe implementar un conjunto de funciones de devolución de llamada que no estaban presentes hasta ahora. • https://git.kernel.org/stable/c/ca69300173b642ba64118200172171ea5967b6c5 https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5 https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091 https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4 https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2 https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6 https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52625 – drm/amd/display: Refactor DMCUB enter/exit idle interface
https://notcve.org/view.php?id=CVE-2023-52625
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Refactor DMCUB enter/exit idle interface [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself. Fixing this issue involves the following: 1. Using a software state to track whether or not we need to start the process to exit idle or notify idle. It's possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all. 2. Refactor any instances of exit/notify idle to use a single wrapper that maintains this SW state. This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don't enter an infinite loop. 3. Make sure we exit out of idle prior to sending any commands or waiting for DMCUB idle. This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface. • https://git.kernel.org/stable/c/820c3870c491946a78950cdf961bf40e28c1025f https://git.kernel.org/stable/c/8e57c06bf4b0f51a4d6958e15e1a99c9520d00fa https://access.redhat.com/security/cve/CVE-2023-52625 https://bugzilla.redhat.com/show_bug.cgi?id=2271682 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52624 – drm/amd/display: Wake DMCUB before executing GPINT commands
https://notcve.org/view.php?id=CVE-2023-52624
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before executing GPINT commands [Why] DMCUB can be in idle when we attempt to interface with the HW through the GPINT mailbox resulting in a system hang. [How] Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep sequence. If the GPINT executes successfully then DMCUB will be put back into sleep after the optional response is returned. It functions similar to the inbox command interface. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Activa DMCUB antes de ejecutar comandos GPINT [Por qué] DMCUB puede estar inactivo cuando intentamos interactuar con el HW a través del buzón GPINT, lo que provoca un bloqueo del sistema. [Cómo] Agregue dc_wake_and_execute_gpint() para ajustar la secuencia de activación, ejecución y suspensión. Si GPINT se ejecuta correctamente, DMCUB volverá a entrar en modo de suspensión después de que se devuelva la respuesta opcional. Funciona de manera similar a la interfaz de comando de la bandeja de entrada. • https://git.kernel.org/stable/c/2ef98c6d753a744e333b7e34b9cf687040fba57d https://git.kernel.org/stable/c/e5ffd1263dd5b44929c676171802e7b6af483f21 https://access.redhat.com/security/cve/CVE-2023-52624 https://bugzilla.redhat.com/show_bug.cgi?id=2271684 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •