CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36908 – blk-iocost: do not WARN if iocg was already offlined
https://notcve.org/view.php?id=CVE-2024-36908
In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-iocost: no ADVERTIR si iocg ya estaba desconectado. En iocg_pay_debt(), se activa una advertencia si 'active_list' está vacía, lo que pretende confirmar que iocg está activo cuando deuda. • https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67 https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6 •
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: 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') •