CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36907 – SUNRPC: add a missing rpc_stat for TCP TLS
https://notcve.org/view.php?id=CVE-2024-36907
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: add a missing rpc_stat for TCP TLS Commit 1548036ef120 ("nfs: make the rpc_stat per net namespace") added functionality to specify rpc_stats function but missed adding it to the TCP TLS functionality. As the result, mounting with xprtsec=tls lead to the following kernel oops. [ 128.984192] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001c [ 128.985058] Mem abort info: [ 128.985372] ESR = 0x0000000096000004 [ 128.985709] EC = 0x25: DABT (current EL), IL = 32 bits [ 128.986176] SET = 0, FnV = 0 [ 128.986521] EA = 0, S1PTW = 0 [ 128.986804] FSC = 0x04: level 0 translation fault [ 128.987229] Data abort info: [ 128.987597] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 128.988169] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 128.988811] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 128.989302] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000106c84000 [ 128.990048] [000000000000001c] pgd=0000000000000000, p4d=0000000000000000 [ 128.990736] Internal error: Oops: 0000000096000004 [#1] SMP [ 128.991168] Modules linked in: nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace netfs uinput dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink qrtr vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common mc vmw_vmci xfs libcrc32c e1000e crct10dif_ce ghash_ce sha2_ce vmwgfx nvme sha256_arm64 nvme_core sr_mod cdrom sha1_ce drm_ttm_helper ttm drm_kms_helper drm sg fuse [ 128.996466] CPU: 0 PID: 179 Comm: kworker/u4:26 Kdump: loaded Not tainted 6.8.0-rc6+ #12 [ 128.997226] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.21805430.BA64.2305221830 05/22/2023 [ 128.998084] Workqueue: xprtiod xs_tcp_tls_setup_socket [sunrpc] [ 128.998701] pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 128.999384] pc : call_start+0x74/0x138 [sunrpc] [ 128.999809] lr : __rpc_execute+0xb8/0x3e0 [sunrpc] [ 129.000244] sp : ffff8000832b3a00 [ 129.000508] x29: ffff8000832b3a00 x28: ffff800081ac79c0 x27: ffff800081ac7000 [ 129.001111] x26: 0000000004248060 x25: 0000000000000000 x24: ffff800081596008 [ 129.001757] x23: ffff80007b087240 x22: ffff00009a509d30 x21: 0000000000000000 [ 129.002345] x20: ffff000090075600 x19: ffff00009a509d00 x18: ffffffffffffffff [ 129.002912] x17: 733d4d4554535953 x16: 42555300312d746e x15: ffff8000832b3a88 [ 129.003464] x14: ffffffffffffffff x13: ffff8000832b3a7d x12: 0000000000000008 [ 129.004021] x11: 0101010101010101 x10: ffff8000150cb560 x9 : ffff80007b087c00 [ 129.004577] x8 : ffff00009a509de0 x7 : 0000000000000000 x6 : 00000000be8c4ee3 [ 129.005026] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff000094d56680 [ 129.005425] x2 : ffff80007b0637f8 x1 : ffff000090075600 x0 : ffff00009a509d00 [ 129.005824] Call trace: [ 129.005967] call_start+0x74/0x138 [sunrpc] [ 129.006233] __rpc_execute+0xb8/0x3e0 [sunrpc] [ 129.006506] rpc_execute+0x160/0x1d8 [sunrpc] [ 129.006778] rpc_run_task+0x148/0x1f8 [sunrpc] [ 129.007204] tls_probe+0x80/0xd0 [sunrpc] [ 129.007460] rpc_ping+0x28/0x80 [sunrpc] [ 129.007715] rpc_create_xprt+0x134/0x1a0 [sunrpc] [ 129.007999] rpc_create+0x128/0x2a0 [sunrpc] [ 129.008264] xs_tcp_tls_setup_socket+0xdc/0x508 [sunrpc] [ 129.008583] process_one_work+0x174/0x3c8 [ 129.008813] worker_thread+0x2c8/0x3e0 [ 129.009033] kthread+0x100/0x110 [ 129.009225] ret_from_fork+0x10/0x20 [ 129.009432] Code: f0ffffc2 911fe042 aa1403e1 aa1303e0 (b9401c83) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: SUNRPC: agrega un rpc_stat faltante para TCP TLS. El commit 1548036ef120 ("nfs: crea rpc_stat por espacio de nombres de red") agregó funcionalidad para especificar la función rpc_stats pero no la agregó a la funcionalidad TCP TLS. . Como resultado, montar con xprtsec=tls conduce a los siguientes errores del kernel. [128.984192] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 000000000000001c [128.985058] Información de cancelación de memoria: [128.985372] ESR = 0x0000000096000004 [128.985709] EC = 0x25: (EL actual), IL = 32 bits [ 128.986176] SET = 0 , FnV = 0 [ 128.986521] EA = 0, S1PTW = 0 [ 128.986804] FSC = 0x04: error de traducción de nivel 0 [ 128.987229] Información de cancelación de datos: [ 128.987597] ISV = 0, ISS = 0x00000004, ISS2 = 0x000 00000 [ 128.988169] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 128.988811] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 128.989302] tabla de páginas de usuario: páginas de 4k, VA de 48 bits, pgdp=0000000106c84000 [ 128.990048] [000000000000001c] pgd=0000000000000000, p4d=0000000000000000 [ 128.990736] Error interno: Ups: 0000000096000004 [#1] SMP [ 168] Módulos vinculados en: nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd Grace netfs uinput dm_mod nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf _rechazar_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink qrtr vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock pc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common mc vmw_vmci xfs libcrc32c e1000e crct10dif_ce ghash_ce sha2_ce vmwgfx nvme sha256_arm64 nvme_core sr_mod cdrom sha1_ce _ttm_helper ttm drm_kms_helper drm sg fusible [ 128.996466 ] CPU: 0 PID: 179 Comm: kworker/u4:26 Kdump: cargado No contaminado 6.8.0-rc6+ #12 [ 128.997226] Nombre de hardware: VMware, Inc. • https://git.kernel.org/stable/c/19f51adc778fb84c2eb07eb71800fb0d9f0ff13a https://git.kernel.org/stable/c/afdbc21a92a0cdc497d8879aeff7b284094fae02 https://git.kernel.org/stable/c/7ceb89f4016ea6ed3e59b015d4200739d45c790e https://git.kernel.org/stable/c/2b7f2d663a965943e8820b6a40cc2abe2eee7431 https://git.kernel.org/stable/c/9b332c72299f2ac284ab3d7c0301969b933e4ca1 https://git.kernel.org/stable/c/024f7744bd09cb2a47a0a96b9c8ad08109de99cc https://git.kernel.org/stable/c/8e088a20dbe33919695a8082c0b32deb62d23b4a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36906 – ARM: 9381/1: kasan: clear stale stack poison
https://notcve.org/view.php?id=CVE-2024-36906
In the Linux kernel, the following vulnerability has been resolved: ARM: 9381/1: kasan: clear stale stack poison We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9381/1: kasan: borrar veneno de pila obsoleta Encontramos el siguiente fallo de OOB: [33.452494] ================== =================================================== [ 33.453513] ERROR: KASAN: pila fuera de los límites en refresco_cpu_vm_stats.constprop.0+0xcc/0x2ec [33.454660] Escritura de tamaño 164 en la dirección c1d03d30 mediante task swapper/0/0 [33.455515] [33.455767] CPU: 0 PID : 0 Comm: swapper/0 Tainted: GO 6.1.25-mainline #1 [ 33.456880] Nombre del hardware: Sistema basado en DT genérico [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.45 9072] dump_stack_lvl de print_report+0x158/0x4a4 [ 33.459863] print_report de kasan_report+0x9c/0x148 [ 33.460616] kasan_report de kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range de memset+0x20/0x 3c [33.462157] conjunto de memorias de refresco_cpu_vm_stats.constprop.0+0xcc/ 0x2ec [33.463064] refresco_cpu_vm_stats.constprop.0 de tick_nohz_idle_stop_tick+0x180/0x53c [33.464181] tick_nohz_idle_stop_tick de do_idle+0x264/0x354 [33.465029] do_idle de cpu_startup _entry+0x20/0x24 [ 33.465769] cpu_startup_entry de rest_init+0xf0/0xf4 [ 33.466528] rest_init de arch_post_acpi_subsys_init+0x0/0x18 [33.467397] [33.467644] La dirección con errores pertenece a la pila de task swapper/0/0 [33.468493] y se encuentra en el desplazamiento 112 en el framework: [33.469172] [ 33.469917 ] [ 33.470165] Este framework tiene 2 objetos: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] La dirección con errores pertenece a la página física: [ 33.47 2862] página:3cd72da8 refcount:1 mapcount:0 mapeo:00000000 índice:0x0 pfn:0x41d03 [ 33.473944] banderas: 0x1000(reservado|zona=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 000000 00000000 ffffffff 00000001 [ 33.475656] sin formato: 00000000 [33.476050] página volcada porque: kasan: mal acceso detectado [33.476816] [33.477061] Estado de la memoria alrededor de la dirección con errores: [33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 [33.478630] c1d03c80 : 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 3.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] === ==================================================== ==== Descubrimos que la causa principal de este OOB es que el brazo no elimina el veneno de la pila obsoleta en el caso de cpuidle. Este parche hace referencia a arch/arm64/kernel/sleep.S para resolver este problema. Del compromiso citado [1] que explica el problema. Las funciones que el compilador ha instrumentado para KASAN colocan veneno en la sombra de la pila al ingresar y eliminan este veneno antes de regresar. • https://git.kernel.org/stable/c/5615f69bc2097452ecc954f5264d784e158d6801 https://git.kernel.org/stable/c/20ac71bee028ffbae4fc14ed679b23b4d3e95726 https://git.kernel.org/stable/c/ad702338fe423cb1e79745787090317256a98dab https://git.kernel.org/stable/c/ee0ce7573e5083031960faf602c9db693ab5b477 https://git.kernel.org/stable/c/b26f353786d365e658cebc9a9ace88e04fc2325e https://git.kernel.org/stable/c/c4238686f9093b98bd6245a348bcf059cdce23af •
CVSS: 9.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36905 – tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
https://notcve.org/view.php?id=CVE-2024-36905
In the Linux kernel, the following vulnerability has been resolved: tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers. In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust() A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called. TCP_CLOSE connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1 To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway. When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state. This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations. [1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: diferir apagado (SEND_SHUTDOWN) para sockets TCP_SYN_RECV El estado TCP_SYN_RECV es realmente especial, solo lo usan conexiones cross-syn, principalmente usado por fuzzers. En el siguiente fallo [1], syzbot logró activar una división por cero en tcp_rcv_space_adjust(). Un socket realiza las siguientes transiciones de estado, sin siquiera llamar a tcp_init_transfer(), lo que significa que tampoco se llama a tcp_init_buffer_space(). TCP_CLOSE connect() TCP_SYN_SENT TCP_SYN_RECV Shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1 Para solucionar este problema, cambie tcp_shutdown() para no realizar una transición TCP_SYN_RECV -> TCP_FIN_WAIT1, lo que de todos modos no tiene sentido. Cuando tcp_rcv_state_process() luego cambie el estado del socket de TCP_SYN_RECV a TCP_ESTABLISH, mire sk->sk_shutdown para finalmente ingresar al estado TCP_FIN_WAIT1 y envíe un paquete FIN desde un estado de socket sano. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/34e41a031fd7523bf1cd00a2adca2370aebea270 https://git.kernel.org/stable/c/ed5e279b69e007ce6c0fe82a5a534c1b19783214 https://git.kernel.org/stable/c/413c33b9f3bc36fdf719690a78824db9f88a9485 https://git.kernel.org/stable/c/2552c9d9440f8e7a2ed0660911ff00f25b90a0a4 https://git.kernel.org/stable/c/3fe4ef0568a48369b1891395d13ac593b1ba41b1 https://git.kernel.org/stable/c/f47d0d32fa94e815fdd78b8b88684873e67939f4 https://git.kernel.org/stable/c/cbf232ba11bc86a5281b4f00e1151349e • CWE-369: Divide By Zero •
CVSS: 7.0EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36904 – tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
https://notcve.org/view.php?id=CVE-2024-36904
In the Linux kernel, the following vulnerability has been resolved: tcp: Use refcount_inc_not_zero() in tcp_twsk_unique(). Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock. Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt. If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else. To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false. [0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? • https://git.kernel.org/stable/c/ec94c2696f0bcd5ae92a553244e4ac30d2171a2d https://git.kernel.org/stable/c/84546cc1aeeb4df3e444b18a4293c9823f974be9 https://git.kernel.org/stable/c/1796ca9c6f5bd50554214053af5f47d112818ee3 https://git.kernel.org/stable/c/1d9cf07810c30ef7948879567d10fd1f01121d34 https://git.kernel.org/stable/c/27b0284d8be182a81feb65581ab6a724dfd596e8 https://git.kernel.org/stable/c/13ed7cdf079686ccd3618335205700c03f6fb446 https://git.kernel.org/stable/c/6e48faad92be13166184d21506e4e54c79c13adc https://git.kernel.org/stable/c/517e32ea0a8c72202d0d8aa8df50a7cd3 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 10EXPL: 0CVE-2024-36903 – ipv6: Fix potential uninit-value access in __ip6_make_skb()
https://notcve.org/view.php?id=CVE-2024-36903
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix potential uninit-value access in __ip6_make_skb() As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige el posible acceso a valores uninit en __ip6_make_skb() Como se hizo en el commit fc1092f51567 ("ipv4: corrige el acceso a valores uninit en __ip_make_skb()") para IPv4, verifique FLOWI_FLAG_KNOWN_NH en fl6->flowi6_flags en lugar de probar HDRINCL en el socket para evitar una condición de ejecución que provoque acceso a valores uninit. • https://git.kernel.org/stable/c/ea30388baebcce37fd594d425a65037ca35e59e8 https://git.kernel.org/stable/c/165370522cc48127da564a08584a7391e6341908 https://git.kernel.org/stable/c/f394f690a30a5ec0413c62777a058eaf3d6e10d5 https://git.kernel.org/stable/c/0cf600ca1bdf1d52df977516ee6cee0cadb1f6b1 https://git.kernel.org/stable/c/605b056d63302ae84eb136e88d4df49124bd5e0d https://git.kernel.org/stable/c/d65ff2fe877c471aa6e79efa7bd8ff66e147c317 https://git.kernel.org/stable/c/2c9cefc142c1dc2759e19a92d3b2b3715e985beb https://git.kernel.org/stable/c/02ed5700f40445af02d1c97db25ffc2d0 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •