CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36965 – remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
https://notcve.org/view.php?id=CVE-2024-36965
In the Linux kernel, the following vulnerability has been resolved: remoteproc: mediatek: Make sure IPI buffer fits in L2TCM The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: mediatek: asegúrese de que el búfer IPI encaje en L2TCM. La ubicación del búfer IPI se lee desde el firmware que cargamos en el procesador System Companion, y no se garantiza que tanto la SRAM ( L2TCM) que se define en el nodo del árbol de dispositivos es lo suficientemente grande para eso, y si bien esto es especialmente cierto para SCP de múltiples núcleos, también es útil verificar las variantes de un solo núcleo. No realizar esta verificación puede hacer que este controlador realice operaciones de lectura y escritura fuera del límite L2TCM, lo que resultará (en el mejor de los casos) en un pánico en el kernel. Para solucionarlo, verifique que el búfer IPI encaje; de lo contrario, devolverá una falla y se negará a iniciar el núcleo SCP relevante (o el SCP en absoluto, si es de un solo núcleo). • https://git.kernel.org/stable/c/3efa0ea743b77d1611501f7d8b4f320d032d73ae https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2 https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9 https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42 •
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: 6.2EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36962 – net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs
https://notcve.org/view.php?id=CVE-2024-36962
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs Currently the driver uses local_bh_disable()/local_bh_enable() in its IRQ handler to avoid triggering net_rx_action() softirq on exit from netif_rx(). The net_rx_action() could trigger this driver .start_xmit callback, which is protected by the same lock as the IRQ handler, so calling the .start_xmit from netif_rx() from the IRQ handler critical section protected by the lock could lead to an attempt to claim the already claimed lock, and a hang. The local_bh_disable()/local_bh_enable() approach works only in case the IRQ handler is protected by a spinlock, but does not work if the IRQ handler is protected by mutex, i.e. this works for KS8851 with Parallel bus interface, but not for KS8851 with SPI bus interface. Remove the BH manipulation and instead of calling netif_rx() inside the IRQ handler code protected by the lock, queue all the received SKBs in the IRQ handler into a queue first, and once the IRQ handler exits the critical section protected by the lock, dequeue all the queued SKBs and push them all into netif_rx(). At this point, it is safe to trigger the net_rx_action() softirq, since the netif_rx() call is outside of the lock that protects the IRQ handler. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ks8851: Cola de paquetes RX en el controlador IRQ en lugar de deshabilitar los BH Actualmente, el controlador usa local_bh_disable()/local_bh_enable() en su controlador IRQ para evitar activar el softirq net_rx_action() al salir de netif_rx(). net_rx_action() podría activar esta devolución de llamada del controlador .start_xmit, que está protegido por el mismo candado que el controlador IRQ, por lo que llamar al .start_xmit desde netif_rx() desde la sección crítica del controlador IRQ protegido por el bloqueo podría llevar a un intento de reclamar el candado ya reclamado y un colgado. El enfoque local_bh_disable()/local_bh_enable() funciona sólo en caso de que el controlador IRQ esté protegido por un spinlock, pero no funciona si el controlador IRQ está protegido por mutex, es decir, esto funciona para KS8851 con interfaz de bus paralelo, pero no para KS8851 con Interfaz de bus SPI. • https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540 https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b https://git.kernel.org/stable/c/8a3ff43dcbab7c96f9e8cf2bd1049ab8d6e59545 https://git.kernel.org/stable/c/ae87f661f3c1a3134a7ed86ab69bf9f12af88993 https://git.kernel.org/stable/c/7e2901a2a9195da76111f351584bf77552a038f0 https://git.kernel.org/stable/c/e0863634bf9f7cf36291ebb5bfa2d16632f79c49 •
CVSS: 4.4EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-36961 https://bugzilla.redhat.com/show_bug.cgi?id=2290407 • CWE-667: Improper Locking •