CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36964 – fs/9p: only translate RWX permissions for plain 9P2000
https://notcve.org/view.php?id=CVE-2024-36964
In the Linux kernel, the following vulnerability has been resolved: fs/9p: only translate RWX permissions for plain 9P2000 Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/9p: solo traduce permisos RWX para 9P2000 simple. Se permite el paso de basura en bits permanentes de 9P2000 simple, lo que hace que pueda establecer (entre otros) el bit suid. Probablemente esta no era la intención, ya que los bits extendidos de Unix se manejan explícita y condicionalmente en .u. • https://git.kernel.org/stable/c/e90bc596a74bb905e0a45bf346038c3f9d1e868d https://git.kernel.org/stable/c/df1962a199783ecd66734d563caf0fedecf08f96 https://git.kernel.org/stable/c/5a605930e19f451294bd838754f7d66c976a8a2c https://git.kernel.org/stable/c/ad4f65328661392de74e3608bb736fedf3b67e32 https://git.kernel.org/stable/c/ca9b5c81f0c918c63d73d962ed8a8e231f840bc8 https://git.kernel.org/stable/c/e55c601af3b1223a84f9f27f9cdbd2af5e203bf3 https://git.kernel.org/stable/c/157d468e34fdd3cb1ddc07c2be32fb3b02826b02 https://git.kernel.org/stable/c/cd25e15e57e68a6b18dc9323047fe9c68 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36963 – tracefs: Reset permissions on remount if permissions are options
https://notcve.org/view.php?id=CVE-2024-36963
In the Linux kernel, the following vulnerability has been resolved: tracefs: Reset permissions on remount if permissions are options There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs). But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated. This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some. For example: # cd /sys/kernel/tracing # chgrp 1002 current_tracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root root 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root root 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root root 0 May 1 21:25 dynamic_events -r--r----- 1 root root 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root root 0 May 1 21:25 enabled_functions Where current_tracer now has group "lkp". # mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffer_size_kb -rw-r----- 1 root tracing 0 May 1 21:25 buffer_subbuf_size_kb -r--r----- 1 root tracing 0 May 1 21:25 buffer_total_size_kb -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamic_events -r--r----- 1 root tracing 0 May 1 21:25 dyn_ftrace_total_info -r--r----- 1 root tracing 0 May 1 21:25 enabled_functions Everything changed but the "current_tracer". Add a new link list that keeps track of all the tracefs_inodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracefs: restablece los permisos al volver a montar si los permisos son opciones. • https://git.kernel.org/stable/c/628adb842bd5e1c2c598534a7a022b8235289de6 https://git.kernel.org/stable/c/8186fff7ab649085e2c60d032d9a20a85af1d87c https://git.kernel.org/stable/c/9c2ac5e0ea7899411fd900d4681890722a020735 https://git.kernel.org/stable/c/5f91fc82794d4a6e41cdcd02d00baa377d94ca78 https://git.kernel.org/stable/c/414fb08628143203d29ccd0264b5a83fb9523c03 https://git.kernel.org/stable/c/baa23a8d4360d981a49913841a726edede5cdd54 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36961 – thermal/debugfs: Fix two locking issues with thermal zone debug
https://notcve.org/view.php?id=CVE-2024-36961
In the Linux kernel, the following vulnerability has been resolved: thermal/debugfs: Fix two locking issues with thermal zone debug With the current thermal zone locking arrangement in the debugfs code, user space can open the "mitigations" file for a thermal zone before the zone's debugfs pointer is set which will result in a NULL pointer dereference in tze_seq_start(). Moreover, thermal_debug_tz_remove() is not called under the thermal zone lock, so it can run in parallel with the other functions accessing the thermal zone's struct thermal_debugfs object. Then, it may clear tz->debugfs after one of those functions has checked it and the struct thermal_debugfs object may be freed prematurely. To address the first problem, pass a pointer to the thermal zone's struct thermal_debugfs object to debugfs_create_file() in thermal_debug_tz_add() and make tze_seq_start(), tze_seq_next(), tze_seq_stop(), and tze_seq_show() retrieve it from s->private instead of a pointer to the thermal zone object. This will ensure that tz_debugfs will be valid across the "mitigations" file accesses until thermal_debugfs_remove_id() called by thermal_debug_tz_remove() removes that file. To address the second problem, use tz->lock in thermal_debug_tz_remove() around the tz->debugfs value check (in case the same thermal zone is removed at the same time in two different threads) and its reset to NULL. Cc :6.8+ <stable@vger.kernel.org> # 6.8+ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/debugfs: soluciona dos problemas de bloqueo con la depuración de la zona térmica. Con la disposición actual de bloqueo de la zona térmica en el código debugfs, el espacio de usuario puede abrir el archivo de "mitigaciones" para una zona térmica antes. El puntero debugfs de la zona está configurado, lo que dará como resultado una desreferencia del puntero NULL en tze_seq_start(). • https://git.kernel.org/stable/c/7ef01f228c9f54c6260319858be138a8a7e9e704 https://git.kernel.org/stable/c/6c57bdd0505422d5ccd2df541d993aec978c842e https://git.kernel.org/stable/c/c7f7c37271787a7f77d7eedc132b0b419a76b4c8 •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36960 – drm/vmwgfx: Fix invalid reads in fence signaled events
https://notcve.org/view.php?id=CVE-2024-36960
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix invalid reads in fence signaled events Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vmwgfx: corrige lecturas no válidas en eventos señalizados de valla establezca correctamente la longitud de drm_event al tamaño de la estructura que realmente se utiliza. La longitud de drm_event se configuró en la estructura principal en lugar de en drm_vmw_event_fence que se supone debe leerse. drm_read usa el parámetro de longitud para copiar el evento al espacio del usuario, lo que resulta en lecturas oob. This vulnerability allows local attackers to disclose sensitive information on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of vmw fence events. • https://git.kernel.org/stable/c/8b7de6aa84682a3396544fd88cd457f95484573a https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9 https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36 https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0 https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22 https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb7242834 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-36959 – pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()
https://notcve.org/view.php?id=CVE-2024-36959
In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map() If we fail to allocate propname buffer, we need to drop the reference count we just took. Because the pinctrl_dt_free_maps() includes the droping operation, here we call it directly. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pinctrl: devicetree: corrige la fuga de recuento de referencia en pinctrl_dt_to_map() Si no asignamos el búfer de nombre de propiedad, debemos eliminar el recuento de referencias que acabamos de tomar. Debido a que pinctrl_dt_free_maps() incluye la operación de eliminación, aquí la llamamos directamente. • https://git.kernel.org/stable/c/a988dcd3dd9e691c5ccc3324b209688f3b5453e9 https://git.kernel.org/stable/c/040f726fecd88121f3b95e70369785ad452dddf9 https://git.kernel.org/stable/c/777430aa4ddccaa5accec6db90ffc1d47f00d471 https://git.kernel.org/stable/c/97e5b508e96176f1a73888ed89df396d7041bfcb https://git.kernel.org/stable/c/91d5c5060ee24fe8da88cd585bb43b843d2f0dce https://git.kernel.org/stable/c/aaf552c5d53abe4659176e099575fe870d2e4768 https://git.kernel.org/stable/c/b4d9f55cd38435358bc16d580612bc0d798d7b4c https://git.kernel.org/stable/c/5834a3a98cd266ad35a229923c0adbd0a •