CVSS: 7.0EPSS: 0%CPEs: 10EXPL: 0CVE-2024-36883 – net: fix out-of-bounds access in ops_init
https://notcve.org/view.php?id=CVE-2024-36883
In the Linux kernel, the following vulnerability has been resolved: net: fix out-of-bounds access in ops_init net_alloc_generic is called by net_alloc, which is called without any locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access. It is possible that the array is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then used to set s.len with a larger than allocated length for the variable array. Fix it by reading max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in net_assign_generic. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrige el acceso fuera de los límites en ops_init net_alloc_generic es llamado por net_alloc, que se llama sin ningún bloqueo. • https://git.kernel.org/stable/c/073862ba5d249c20bd5c49fc6d904ff0e1f6a672 https://git.kernel.org/stable/c/561331eae0a03d0c4cf60f3cf485aa3e8aa5ab48 https://git.kernel.org/stable/c/a2c82f7bee1ffa9eafa1fb0bd886a7eea8c9e497 https://git.kernel.org/stable/c/3cdc34d76c4f777579e28ad373979d36c030cfd3 https://git.kernel.org/stable/c/7b0e64583eab8c1d896b47e5dd0bf2e7d86ec41f https://git.kernel.org/stable/c/0c3248bc708a7797be573214065cf908ff1f54c7 https://git.kernel.org/stable/c/9518b79bfd2fbf99fa9b7e8e36bcb1825e7ba030 https://git.kernel.org/stable/c/2d60ff5874aefd006717ca5e22ac1e25e • CWE-787: Out-of-bounds Write •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36026 – drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11
https://notcve.org/view.php?id=CVE-2024-36026
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11 While doing multiple S4 stress tests, GC/RLC/PMFW get into an invalid state resulting into hard hangs. Adding a GFX reset as workaround just before sending the MP1_UNLOAD message avoids this failure. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/pm: corrige un bloqueo aleatorio en S4 para SMU v13.0.4/11 Al realizar múltiples pruebas de estrés de S4, GC/RLC/PMFW entra en un estado no válido, lo que resulta en cuelga duro. Agregar un reinicio de GFX como workaround justo antes de enviar el mensaje MP1_UNLOAD evita este error. • https://git.kernel.org/stable/c/bd9b94055c3deb2398ee4490c1dfdf03f53efb8f https://git.kernel.org/stable/c/1e3b8874d55c0c28378beb9007494a7a9269a5f5 https://git.kernel.org/stable/c/7521329e54931ede9e042bbf5f4f812b5bc4a01d https://git.kernel.org/stable/c/31729e8c21ecfd671458e02b6511eb68c2225113 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36024 – drm/amd/display: Disable idle reallow as part of command/gpint execution
https://notcve.org/view.php?id=CVE-2024-36024
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable idle reallow as part of command/gpint execution [Why] Workaroud for a race condition where DMCUB is in the process of committing to IPS1 during the handshake causing us to miss the transition into IPS2 and touch the INBOX1 RPTR causing a HW hang. [How] Disable the reallow to ensure that we have enough of a gap between entry and exit and we're not seeing back-to-back wake_and_executes. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: deshabilite la reasignación inactiva como parte de la ejecución del comando/gpint [Por qué] Workaroud para una condición de ejecución en la que DMCUB está en el proceso de comprometerse con IPS1 durante el protocolo de enlace que causa Nos perdemos la transición a IPS2 y tocamos el RPTR de INBOX1 provocando un bloqueo del HW. [Cómo] Deshabilite la reallow para asegurarnos de que tengamos un espacio suficiente entre la entrada y la salida y que no veamos wake_and_executes consecutivos. • https://git.kernel.org/stable/c/2aac387445610d6dfd681f5214388e86f5677ef7 https://git.kernel.org/stable/c/6226a5aa77370329e01ee8abe50a95e60618ce97 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36023 – Julia Lawall reported this null pointer dereference, this should fix it.
https://notcve.org/view.php?id=CVE-2024-36023
In the Linux kernel, the following vulnerability has been resolved: Julia Lawall reported this null pointer dereference, this should fix it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Julia Lawall informó esta desreferencia de puntero nulo, esto debería solucionarlo. • https://git.kernel.org/stable/c/2e2177f94c0e0bc41323d7b6975a5f4820ed347e https://git.kernel.org/stable/c/214a6c4a28c11d67044e6cf3a0ab415050d9f03a https://git.kernel.org/stable/c/b972e8ac3f44f693127a2806031962d100dfc4d1 https://git.kernel.org/stable/c/9bf93dcfc453fae192fe5d7874b89699e8f800ac • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36022 – drm/amdgpu: Init zone device and drm client after mode-1 reset on reload
https://notcve.org/view.php?id=CVE-2024-36022
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Init zone device and drm client after mode-1 reset on reload In passthrough environment, when amdgpu is reloaded after unload, mode-1 is triggered after initializing the necessary IPs, That init does not include KFD, and KFD init waits until the reset is completed. KFD init is called in the reset handler, but in this case, the zone device and drm client is not initialized, causing app to create kernel panic. v2: Removing the init KFD condition from amdgpu_amdkfd_drm_client_create. As the previous version has the potential of creating DRM client twice. v3: v2 patch results in SDMA engine hung as DRM open causes VM clear to SDMA before SDMA init. Adding the condition to in drm client creation, on top of v1, to guard against drm client creation call multiple times. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: dispositivo de zona de inicio y cliente drm después del restablecimiento del modo 1 al recargar. En el entorno de paso a través, cuando amdgpu se recarga después de la descarga, el modo 1 se activa después de inicializar las IP necesarias. • https://git.kernel.org/stable/c/4f8154f775197d0021b690c2945d6a4d8094c8f6 https://git.kernel.org/stable/c/f679fd6057fbf5ab34aaee28d58b7f81af0cbf48 •