CVSS: 5.3EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52699 – sysv: don't call sb_bread() with pointers_lock held
https://notcve.org/view.php?id=CVE-2023-52699
In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sysv: no llame a sb_bread() con pointers_lock retenido syzbot informa suspensión en contexto atómico en el sistema de archivos SysV [1], porque sb_bread() se llama con rw_spinlock retenido. Un error "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" y un error "sb_bread() with write_lock(&pointers_lock)" fueron introducidos por "Reemplazar BKL para bloqueo de cadena con sysvfs-private rwlock" en Linux 2.5.12. Luego, "[PATCH] err1-40: corrección de bloqueo de sysvfs" en Linux 2.6.8 solucionó el error anterior moviendo el bloqueo pointers_lock a las personas que llaman, pero en su lugar introdujo un error "sb_bread() con read_lock(&pointers_lock)" (que hizo que esto problema más fácil de abordar). • https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76 https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1 https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927 https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09 https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3 https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441ab •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35915 – nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
https://notcve.org/view.php?id=CVE-2024-35915
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_dev_up y nci_ntf_packet syzbot informó el siguiente problema de acceso al valor uninit [1][2]: nci_rx_work() analiza y procesa el paquete recibido. Cuando la longitud del payload es cero, cada controlador de tipo de mensaje lee el payload no inicializado y KMSAN detecta este problema. • https://git.kernel.org/stable/c/6a2968aaf50c7a22fced77a5e24aa636281efca8 https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240 https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16 https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f600 •
CVSS: 5.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35910 – tcp: properly terminate timers for kernel sockets
https://notcve.org/view.php?id=CVE-2024-35910
In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns. For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns. This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler. Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held. It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code) We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: termina correctamente los temporizadores para los sockets del kernel. Recibimos varios informes de syzbot sobre los temporizadores tcp que se activan después de que se han desmantelado las redes correspondientes. Afortunadamente, Josef Bacik pudo provocar el problema con más frecuencia y pudo probar un parche que escribí hace dos años. Cuando los sockets TCP están cerrados, llamamos a inet_csk_clear_xmit_timers() para "detener" los temporizadores. • https://git.kernel.org/stable/c/8a68173691f036613e3d4e6bf8dc129d4a7bf383 https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50 https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810 https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4 https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87 https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35905 – bpf: Protect against int overflow for stack access size
https://notcve.org/view.php?id=CVE-2024-35905
In the Linux kernel, the following vulnerability has been resolved: bpf: Protect against int overflow for stack access size This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail. This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Protección contra desbordamiento int para el tamaño de acceso a la pila. • https://git.kernel.org/stable/c/afea95d319ccb4ad2060dece9ac5e2e364dec543 https://git.kernel.org/stable/c/02962684258eb53f414a8a59854767be526e6abb https://git.kernel.org/stable/c/b1d4d54d32ce6342f5faffe71bae736540ce7cb5 https://git.kernel.org/stable/c/08b91babccbb168353f8d43fea0ed28a4cad568c https://git.kernel.org/stable/c/a833a17aeac73b33f79433d7cee68d5cafd71e4f https://git.kernel.org/stable/c/1858b8a331937f3976d8482cd5f6e1f945294ad3 https://git.kernel.org/stable/c/9970e059af471478455f9534e8c3db82f8c5496d https://git.kernel.org/stable/c/37dc1718dc0c4392dbfcb9adec22a776e •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35904 – selinux: avoid dereference of garbage after mount failure
https://notcve.org/view.php?id=CVE-2024-35904
In the Linux kernel, the following vulnerability has been resolved: selinux: avoid dereference of garbage after mount failure In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer. While on it drop the never read static variable selinuxfs_mount. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: evita la desreferenciación de basura después de un error de montaje En caso de que kern_mount() falle y devuelva un puntero de error en la rama de error en lugar de continuar y desreferenciar el puntero de error. Mientras está en él, suelte la variable estática nunca leída selinuxfs_mount. • https://git.kernel.org/stable/c/0619f0f5e36f12e100ef294f5980cfe7c93ff23e https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b http://www.openwall.com/lists/oss-security/2024/05/30/1 http://www.openwall.com/lists/oss-security/2024/05/30/2 •