CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41007 – tcp: avoid too many retransmit packets
https://notcve.org/view.php?id=CVE-2024-41007
In the Linux kernel, the following vulnerability has been resolved: tcp: avoid too many retransmit packets If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has 'expired'. The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account. Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits. Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: evitar demasiados paquetes de retransmisión Si un socket TCP está usando TCP_USER_TIMEOUT y el otro par retrajo su ventana a cero, tcp_retransmit_timer() puede retransmitir un paquete cada dos santiamén (2 ms). para HZ=1000), durante aproximadamente 4 minutos después de que TCP_USER_TIMEOUT haya 'expirado'. La solución es asegurarse de que tcp_rtx_probe0_timed_out() tenga en cuenta icsk->icsk_user_timeout. Antes de el commit culpable, el socket no expiraba después de icsk->icsk_user_timeout, sino que usaba un retroceso exponencial estándar para las retransmisiones. También vale la pena señalar que antes de commit e89688e3e978 ("net: tcp: fix unexcepted socket die cuando snd_wnd es 0"), el problema duraría 2 minutos en lugar de 4. • https://git.kernel.org/stable/c/b701a99e431db784714c32fc6b68123045714679 https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4 https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969 https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982 https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570 https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466 https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b054625 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52885 – SUNRPC: Fix UAF in svc_tcp_listen_data_ready()
https://notcve.org/view.php?id=CVE-2023-52885
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix UAF in svc_tcp_listen_data_ready() After the listener svc_sock is freed, and before invoking svc_tcp_accept() for the established child sock, there is a window that the newsock retaining a freed listener svc_sock in sk_user_data which cloning from parent. In the race window, if data is received on the newsock, we will observe use-after-free report in svc_tcp_listen_data_ready(). Reproduce by two tasks: 1. while :; do rpc.nfsd 0 ; rpc.nfsd; done 2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] Read of size 8 at addr ffff888139d96228 by task nc/102553 CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <IRQ> dump_stack_lvl+0x33/0x50 print_address_description.constprop.0+0x27/0x310 print_report+0x3e/0x70 kasan_report+0xae/0xe0 svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] tcp_data_queue+0x9f4/0x20e0 tcp_rcv_established+0x666/0x1f60 tcp_v4_do_rcv+0x51c/0x850 tcp_v4_rcv+0x23fc/0x2e80 ip_protocol_deliver_rcu+0x62/0x300 ip_local_deliver_finish+0x267/0x350 ip_local_deliver+0x18b/0x2d0 ip_rcv+0x2fb/0x370 __netif_receive_skb_one_core+0x166/0x1b0 process_backlog+0x24c/0x5e0 __napi_poll+0xa2/0x500 net_rx_action+0x854/0xc90 __do_softirq+0x1bb/0x5de do_softirq+0xcb/0x100 </IRQ> <TASK> ... </TASK> Allocated by task 102371: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7b/0x90 svc_setup_socket+0x52/0x4f0 [sunrpc] svc_addsock+0x20d/0x400 [sunrpc] __write_ports_addfd+0x209/0x390 [nfsd] write_ports+0x239/0x2c0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 102551: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x190 __kmem_cache_free+0x133/0x270 svc_xprt_free+0x1e2/0x350 [sunrpc] svc_xprt_destroy_all+0x25a/0x440 [sunrpc] nfsd_put+0x125/0x240 [nfsd] nfsd_svc+0x2cb/0x3c0 [nfsd] write_threads+0x1ac/0x2a0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready() if state != TCP_LISTEN, that will avoid dereferencing svsk for all child socket. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: corrige UAF en svc_tcp_listen_data_ready() Después de que se libera el oyente svc_sock, y antes de invocar svc_tcp_accept() para el calcetín secundario establecido, hay una ventana que indica que el newsock retiene un oyente liberado. svc_sock en sk_user_data que clona desde el padre. • https://git.kernel.org/stable/c/fa9251afc33c81606d70cfe91800a779096442ec https://git.kernel.org/stable/c/c7b8c2d06e437639694abe76978e915cfb73f428 https://git.kernel.org/stable/c/dfc896c4a75cb8cd7cb2dfd9b469cf1e3f004254 https://git.kernel.org/stable/c/42725e5c1b181b757ba11d804443922982334d9b https://git.kernel.org/stable/c/cd5ec3ee52ce4b7e283cc11facfa420c297c8065 https://git.kernel.org/stable/c/fbf4ace39b2e4f3833236afbb2336edbafd75eee https://git.kernel.org/stable/c/ef047411887ff0845afd642d6a687819308e1a4e https://git.kernel.org/stable/c/7e1f989055622fd086c5dfb291fc72adf •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-41006 – netrom: Fix a memory leak in nr_heartbeat_expiry()
https://notcve.org/view.php?id=CVE-2024-41006
In the Linux kernel, the following vulnerability has been resolved: netrom: Fix a memory leak in nr_heartbeat_expiry() syzbot reported a memory leak in nr_create() [0]. Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sock_hold() to the nr_heartbeat_expiry() function, where a) a socket has a SOCK_DESTROY flag or b) a listening socket has a SOCK_DEAD flag. But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor has already been closed and the nr_release() function has been called. So it makes no sense to hold the reference count because no one will call another nr_destroy_socket() and put it as in the case "b." nr_connect nr_establish_data_link nr_start_heartbeat nr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame switch (nr->state) case NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->state = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry switch (nr->state) case NR_STATE_0 if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket() To fix the memory leak, let's call sock_hold() only for a listening socket. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16 • https://git.kernel.org/stable/c/a31caf5779ace8fa98b0d454133808e082ee7a1b https://git.kernel.org/stable/c/fe9b9e621cebe6b7e83f7e954c70f8bb430520e5 https://git.kernel.org/stable/c/7de16d75b20ab13b75a7291f449a1b00090edfea https://git.kernel.org/stable/c/d2d3ab1b1de3302de2c85769121fd4f890e47ceb https://git.kernel.org/stable/c/51e394c6f81adbfe7c34d15f58b3d4d44f144acf https://git.kernel.org/stable/c/409db27e3a2eb5e8ef7226ca33be33361b3ed1c9 https://git.kernel.org/stable/c/e666990abb2e42dd4ba979b4706280a3664cfae7 https://git.kernel.org/stable/c/d616876256b38ecf9a1a1c7d674192c53 •
CVSS: 4.7EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41005 – netpoll: Fix race condition in netpoll_owner_active
https://notcve.org/view.php?id=CVE-2024-41005
In the Linux kernel, the following vulnerability has been resolved: netpoll: Fix race condition in netpoll_owner_active KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) <snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU. • https://git.kernel.org/stable/c/43c0ca793a18578a0f5b305dd77fcf7ed99f1265 https://git.kernel.org/stable/c/efd29cd9c7b8369dfc7bcb34637e6bf1a188aa8e https://git.kernel.org/stable/c/96826b16ef9c6568d31a1f6ceaa266411a46e46c https://git.kernel.org/stable/c/3f1a155950a1685ffd0fd7175b3f671da8771f3d https://git.kernel.org/stable/c/a130e7da73ae93afdb4659842267eec734ffbd57 https://git.kernel.org/stable/c/c2e6a872bde9912f1a7579639c5ca3adf1003916 https://access.redhat.com/security/cve/CVE-2024-41005 https://bugzilla.redhat.com/show_bug.cgi?id=2297589 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41002 – crypto: hisilicon/sec - Fix memory leak for sec resource release
https://notcve.org/view.php?id=CVE-2024-41002
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - Fix memory leak for sec resource release The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs. The aiv resource release is added to the sec resource release function. • https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2 https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6 https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601 https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47 https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094 •