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: 3EXPL: 0CVE-2024-35794 – dm-raid: really frozen sync_thread during suspend
https://notcve.org/view.php?id=CVE-2024-35794
In the Linux kernel, the following vulnerability has been resolved: dm-raid: really frozen sync_thread during suspend 1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend. Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test won't hang there anymore, however, the test will still fail and complain that ext4 is corrupted. And with this patch, the test won't hang due to stop_sync_thread() or fail due to ext4 is corrupted anymore. • https://git.kernel.org/stable/c/9dbd1aa3a81c6166608fec87994b6c464701f73a https://git.kernel.org/stable/c/af916cb66a80597f3523bc85812e790bcdcfd62b https://git.kernel.org/stable/c/eaa8fc9b092837cf2c754bde1a15d784ce9a85ab https://git.kernel.org/stable/c/16c4770c75b1223998adbeb7286f9a15c65fba73 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35790 – usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
https://notcve.org/view.php?id=CVE-2024-35790
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: typec: altmodes/displayport: cree nodos sysfs como grupo de atributos de dispositivo predeterminado del controlador Los nodos sysfs del controlador DisplayPort pueden estar presentes en el espacio de usuario antes de que typec_altmode_set_drvdata() se complete en dp_altmode_probe. Esto significa que una lectura de sysfs puede desencadenar un error de puntero NULL al hacer una diferencia entre dp->hpd en hpd_show o dp->lock en pin_assignment_show, ya que dev_get_drvdata() devuelve NULL en esos casos. • https://git.kernel.org/stable/c/0e3bb7d6894d9b6e67d6382bb03a46a1dc989588 https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0 https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9 https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531 https://access.redhat.com/security/cve/CVE-2024-35790 https://bugzilla.redhat.com/show_bug.cgi?id=2281054 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35789 – wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
https://notcve.org/view.php?id=CVE-2024-35789
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: comprobar/borrar fast rx para cambios de VLAN que no sean 4addr sta Al mover una estación fuera de una VLAN y eliminar la VLAN después, la entrada fast_rx todavía contiene un puntero a netdev de la VLAN, lo que puede causar errores de uso después de la liberación. Solucione este problema llamando inmediatamente a ieee80211_check_fast_rx después del cambio de VLAN. • https://git.kernel.org/stable/c/ea9a0cfc07a7d3601cc680718d9cff0d6927a921 https://git.kernel.org/stable/c/be1dd9254fc115321d6fbee042026d42afc8d931 https://git.kernel.org/stable/c/e8b067c4058c0121ac8ca71559df8e2e08ff1a7e https://git.kernel.org/stable/c/c8bddbd91bc8e42c961a5e2cec20ab879f21100f https://git.kernel.org/stable/c/7eeabcea79b67cc29563e6a9a5c81f9e2c664d5b https://git.kernel.org/stable/c/6b948b54c8bd620725e0c906e44b10c0b13087a7 https://git.kernel.org/stable/c/2884a50f52313a7a911de3afcad065ddbb3d78fc https://git.kernel.org/stable/c/e8678551c0243f799b4859448781cbec1 •