CVSS: -EPSS: 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 •
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: 6.0EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52626 – net/mlx5e: Fix operation precedence bug in port timestamping napi_poll context
https://notcve.org/view.php?id=CVE-2023-52626
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix operation precedence bug in port timestamping napi_poll context Indirection (*) is of lower precedence than postfix increment (++). Logic in napi_poll context would cause an out-of-bound read by first increment the pointer address by byte address space and then dereference the value. Rather, the intended logic was to dereference first and then increment the underlying value. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: se corrigió el error de precedencia de operación en la marca de tiempo del puerto contexto napi_poll La indirección (*) tiene menor prioridad que el incremento de postfijo (++). La lógica en el contexto napi_poll provocaría una lectura fuera de los límites al incrementar primero la dirección del puntero por espacio de direcciones de bytes y luego desreferenciar el valor. Más bien, la lógica prevista era desreferenciar primero y luego incrementar el valor subyacente. • https://git.kernel.org/stable/c/e5d30f7da35720060299483e65fc372980a82dfb https://git.kernel.org/stable/c/92214be5979c0961a471b7eaaaeacab41bdf456c https://git.kernel.org/stable/c/42b11d1293e5a0f932c0b6e891b2c7bae57b839d https://git.kernel.org/stable/c/40e0d0746390c5b0c31144f4f1688d72f3f8d790 https://git.kernel.org/stable/c/33cdeae8c6fb58cc445f859b67c014dc9f60b4e0 https://git.kernel.org/stable/c/3876638b2c7ebb2c9d181de1191db0de8cac143a https://access.redhat.com/security/cve/CVE-2023-52626 https://bugzilla.redhat.com/show_bug.cgi?id=2271680 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 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 •
CVSS: -EPSS: 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 •