CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35805 – dm snapshot: fix lockup in dm_exception_table_exit
https://notcve.org/view.php?id=CVE-2024-35805
In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm snapshot: corregido el bloqueo en dm_exception_table_exit Se informó un bloqueo cuando salimos de un snapshot con muchas excepciones. Solucione este problema agregando "cond_resched" al bucle que libera las excepciones. • https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7 https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1 https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2 https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366 https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683 https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef285 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35803 – x86/efistub: Call mixed mode boot services on the firmware's stack
https://notcve.org/view.php?id=CVE-2024-35803
In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/efistub: llame a los servicios de arranque en modo mixto en la pila del firmware. • https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926 https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31 https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02 •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35801 – x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
https://notcve.org/view.php?id=CVE-2024-35801
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: mantenga xfd_state sincronizado con MSR_IA32_XFD Confirme 672365477ae8 ("x86/fpu: actualice el estado de XFD cuando sea necesario") y confirme 8bf26758ca96 ("x86/fpu: agregue el estado de XFD a fpstate") introdujo una variable xfd_state por CPU para mantener el valor MSR_IA32_XFD en caché, a fin de evitar escrituras innecesarias en el MSR. En la conexión en caliente de la CPU, MSR_IA32_XFD se restablece a init_fpstate.xfd, lo que elimina cualquier estado obsoleto. Pero el valor xfd almacenado en caché por CPU no se restablece, lo que los desincroniza. • https://git.kernel.org/stable/c/672365477ae8afca5a1cca98c1deb733235e4525 https://git.kernel.org/stable/c/21c7c00dae55cb0e3810d5f9506b58f68475d41d https://git.kernel.org/stable/c/1acbca933313aa866e39996904c9aca4d435c4cd https://git.kernel.org/stable/c/92b0f04e937665bde5768f3fcc622dcce44413d8 https://git.kernel.org/stable/c/b61e3b7055ac6edee4be071c52f48c26472d2624 https://git.kernel.org/stable/c/10e4b5166df9ff7a2d5316138ca668b42d004422 https://access.redhat.com/security/cve/CVE-2024-35801 https://bugzilla.redhat.com/show_bug.cgi?id=2281235 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35800 – efi: fix panic in kdump kernel
https://notcve.org/view.php?id=CVE-2024-35800
In the Linux kernel, the following vulnerability has been resolved: efi: fix panic in kdump kernel Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: arreglado el pánico en el kernel kdump. Compruebe si get_next_variable() es realmente un puntero válido antes de llamarlo. En el kernel kdump, este método está configurado en NULL, lo que provoca pánico durante el arranque del kernel kexec-ed. • https://git.kernel.org/stable/c/a8901f331b8b7f95a7315d033a22bc84c8365f35 https://git.kernel.org/stable/c/bad267f9e18f8e9e628abd1811d2899b1735a4e1 https://git.kernel.org/stable/c/b9d103aca85f082a343b222493f3cab1219aaaf4 https://git.kernel.org/stable/c/9114ba9987506bcfbb454f6e68558d68cb1abbde https://git.kernel.org/stable/c/7784135f134c13af17d9ffb39a57db8500bc60ff https://git.kernel.org/stable/c/090d2b4515ade379cd592fbc8931344945978210 https://git.kernel.org/stable/c/62b71cd73d41ddac6b1760402bbe8c4932e23531 https://access.redhat.com/security/cve/CVE-2024-35800 •
CVSS: 6.2EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35799 – drm/amd/display: Prevent crash when disable stream
https://notcve.org/view.php?id=CVE-2024-35799
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Prevent crash when disable stream [Why] Disabling stream encoder invokes a function that no longer exists. [How] Check if the function declaration is NULL in disable stream encoder. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: evita fallos al deshabilitar la transmisión [Por qué] Al deshabilitar el codificador de transmisión se invoca una función que ya no existe. [Cómo] Compruebe si la declaración de función es NULL al desactivar el codificador de flujo. • https://git.kernel.org/stable/c/4356a2c3f296503c8b420ae8adece053960a9f06 https://git.kernel.org/stable/c/59772327d439874095516673b4b30c48bd83ca38 https://git.kernel.org/stable/c/2b17133a0a2e0e111803124dad09e803718d4a48 https://git.kernel.org/stable/c/72d72e8fddbcd6c98e1b02d32cf6f2b04e10bd1c • CWE-400: Uncontrolled Resource Consumption •