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 •
CVSS: 6.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35899 – netfilter: nf_tables: flush pending destroy work before exit_net release
https://notcve.org/view.php?id=CVE-2024-35899
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: flush pending destroy work before exit_net release Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? • https://git.kernel.org/stable/c/0935d558840099b3679c67bb7468dc78fcbad940 https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86 https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31 https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49 https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7 https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6 https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4b • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35898 – netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
https://notcve.org/view.php?id=CVE-2024-35898
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: corrige una posible ejecución de datos en __nft_flowtable_type_get() nft_unregister_flowtable_type() dentro de nf_flow_inet_module_exit() puede coincidir con __nft_flowtable_type_get() dentro de nf_tables_newflowtable(). Y no hay ninguna protección cuando se itera sobre la lista nf_tables_flowtables en __nft_flowtable_type_get(). Por lo tanto, existe una posible ejecución de datos de la entrada de la lista nf_tables_flowtables. • https://git.kernel.org/stable/c/3b49e2e94e6ebb8b23d0955d9e898254455734f8 https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007 https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77 https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331 https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8 https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871 •