CVSS: -EPSS: 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: 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 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35902 – net/rds: fix possible cp null dereference
https://notcve.org/view.php?id=CVE-2024-35902
In the Linux kernel, the following vulnerability has been resolved: net/rds: fix possible cp null dereference cp might be null, calling cp->cp_conn would produce null dereference [Simon Horman adds:] Analysis: * cp is a parameter of __rds_rdma_map and is not reassigned. * The following call-sites pass a NULL cp argument to __rds_rdma_map() - rds_get_mr() - rds_get_mr_for_dest * Prior to the code above, the following assumes that cp may be NULL (which is indicative, but could itself be unnecessary) trans_private = rs->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED); * The code modified by this patch is guarded by IS_ERR(trans_private), where trans_private is assigned as per the previous point in this analysis. The only implementation of get_mr that I could locate is rds_ib_get_mr() which can return an ERR_PTR if the conn (4th) argument is NULL. * ret is set to PTR_ERR(trans_private). rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute. Conclusion: * cp may be NULL at the point where this patch adds a check; this patch does seem to address a possible bug En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/rds: corrige la posible desreferencia nula de cp cp podría ser nulo, llamar a cp->cp_conn produciría una desreferencia nula [Simon Horman agrega:] Análisis: * cp es un parámetro de __rds_rdma_map y no es reasignado. * Los siguientes sitios de llamadas pasan un argumento cp NULL a __rds_rdma_map() - rds_get_mr() - rds_get_mr_for_dest * Antes del código anterior, lo siguiente supone que cp puede ser NULL (lo cual es indicativo, pero podría ser innecesario) trans_private = rs ->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED); * El código modificado por este parche está custodiado por IS_ERR(trans_private), donde trans_private se asigna según el punto anterior de este análisis. • https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4 https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2 https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0 https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80 https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85 https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38 https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a18 •