CVSS: 8.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-5629 – Out-of-bounds read in bson module of PyMongo
https://notcve.org/view.php?id=CVE-2024-5629
An out-of-bounds read in the 'bson' module of PyMongo 4.6.2 or earlier allows deserialization of malformed BSON provided by a Server to raise an exception which may contain arbitrary application memory. Una lectura fuera de los límites en el módulo 'bson' de PyMongo 4.6.2 o anterior permite la deserialización de BSON mal formado proporcionado por un servidor para generar una excepción que puede contener memoria de aplicación arbitraria. • https://jira.mongodb.org/browse/PYTHON-4305 https://lists.debian.org/debian-lts-announce/2024/06/msg00007.html • CWE-125: Out-of-bounds Read •
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. ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/9p: solo traduce permisos RWX para 9P2000 simple. • 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. ... 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(). ... 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. • 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: -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. ... 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. • https://git.kernel.org/stable/c/7ef01f228c9f54c6260319858be138a8a7e9e704 https://git.kernel.org/stable/c/6c57bdd0505422d5ccd2df541d993aec978c842e https://git.kernel.org/stable/c/c7f7c37271787a7f77d7eedc132b0b419a76b4c8 •