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: 7EXPL: 0CVE-2024-35804 – KVM: x86: Mark target gfn of emulated atomic instruction as dirty
https://notcve.org/view.php?id=CVE-2024-35804
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Mark target gfn of emulated atomic instruction as dirty When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty. Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase. Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit. Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging. base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: marcar el gfn de destino de la instrucción atómica emulada como sucia Al emular un acceso atómico en nombre del invitado, marque el gfn de destino como sucio si se intenta realizar el CMPXCHG por KVM y no falla. • https://git.kernel.org/stable/c/d97c0667c1e61ded6639117b4b9584a9c12b7e66 https://git.kernel.org/stable/c/1c2361f667f3648855ceae25f1332c18413fdb9f https://git.kernel.org/stable/c/b0f294103f4cf733e23d3f0c4e5fd58e42998921 https://git.kernel.org/stable/c/e964665cc7ca13a16992b205fce63554b9efc78b https://git.kernel.org/stable/c/a9bd6bb6f02bf7132c1ab192ba62bbfa52df7d66 https://git.kernel.org/stable/c/726374dde5d608b15b9756bd52b6fc283fda7a06 https://git.kernel.org/stable/c/9d1b22e573a3789ed1f32033ee709106993ba551 https://git.kernel.org/stable/c/225d587a073584946c05c9b7651d637bd •
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: 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35796 – net: ll_temac: platform_get_resource replaced by wrong function
https://notcve.org/view.php?id=CVE-2024-35796
In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: platform_get_resource replaced by wrong function The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name. This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name)) It should have been replaced with devm_platform_ioremap_resource. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:ll_temac: platform_get_resource reemplazada por una función incorrecta La función platform_get_resource fue reemplazada por devm_platform_ioremap_resource_byname y se llama usando 0 como nombre. Esto eventualmente termina en platform_get_resource_byname en la pila de llamadas, donde genera un puntero null en strcmp. if (type == Resource_type(r) && !strcmp(r->name, name)) Debería haber sido reemplazado por devm_platform_ioremap_resource. • https://git.kernel.org/stable/c/bd69058f50d5ffa659423bcfa6fe6280ce9c760a https://git.kernel.org/stable/c/77c8cfdf808410be84be56aff7e0e186b8c5a879 https://git.kernel.org/stable/c/6d9395ba7f85bdb7af0b93272e537484ecbeff48 https://git.kernel.org/stable/c/553d294db94b5f139378022df480a9fb6c3ae39e https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3 https://git.kernel.org/stable/c/476eed5f1c22034774902a980aa48dc4662cb39a https://git.kernel.org/stable/c/7e9edb569fd9f688d887e36db8170f6e22bafbc8 https://git.kernel.org/stable/c/92c0c29f667870f17c0b764544bdf22ce •