CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-53125 – bpf: sync_linked_regs() must preserve subreg_def
https://notcve.org/view.php?id=CVE-2024-53125
In the Linux kernel, the following vulnerability has been resolved: bpf: sync_linked_regs() must preserve subreg_def Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: sync_linked_regs() debe preservar subreg_def La propagación del rango no debe afectar a las marcas subreg_def, de lo contrario el siguiente ejemplo es reescrito incorrectamente por el verificador cuando el indicador BPF_F_TEST_RND_HI32 está establecido: 0: llamar a bpf_ktime_get_ns llamar a bpf_ktime_get_ns 1: r0 &= 0x7fffffff después del verificador r0 &= 0x7fffffff 2: w1 = w0 reescribe w1 = w0 3: si w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: salir; si w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 salir (o falta la extensión cero de w1 en (2) para arquitecturas que requieren extensión cero para la mitad superior del registro). • https://git.kernel.org/stable/c/75748837b7e56919679e02163f45d5818c644d03 https://git.kernel.org/stable/c/dadf82c1b2608727bcc306843b540cd7414055a7 https://git.kernel.org/stable/c/b57ac2d92c1f565743f6890a5b9cf317ed856b09 https://git.kernel.org/stable/c/60fd3538d2a8fd44c41d25088c0ece3e1fd30659 https://git.kernel.org/stable/c/bfe9446ea1d95f6cb7848da19dfd58d2eec6fd84 https://git.kernel.org/stable/c/e2ef0f317a52e678fe8fa84b94d6a15b466d6ff0 https://git.kernel.org/stable/c/e9bd9c498cb0f5843996dbe5cbce7a1836a83c70 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53124 – net: fix data-races around sk->sk_forward_alloc
https://notcve.org/view.php?id=CVE-2024-53124
In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fix data-races around sk->sk_forward_alloc Syzkaller informó esta advertencia: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 16 en net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Módulos vinculados: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 No contaminado 6.12.0-rc5 #26 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Código: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? • https://git.kernel.org/stable/c/e994b2f0fb9229aeff5eea9541320bd7b2ca8714 https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6 https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cb •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53123 – mptcp: error out earlier on disconnect
https://notcve.org/view.php?id=CVE-2024-53123
In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 <f7> 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: error anterior al desconectar Eric informó de un error de división por cero en el protocolo MPTCP: Oops: error de división: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 No contaminado 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Código: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 00000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [en línea] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [en línea] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [en línea] __se_sys_recvfrom net/socket.c:2279 [en línea] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef y proporcionó un buen reproductor. • https://git.kernel.org/stable/c/ec9bc89a018842006d63f6545c50768e79bd89f8 https://git.kernel.org/stable/c/419ce133ab928ab5efd7b50b2ef36ddfd4eadbd2 https://git.kernel.org/stable/c/30fa7600e0580cabbbc50e1c94b5609a85469809 https://git.kernel.org/stable/c/a749b23059b43a9b1787eb36c5d9d44150a34238 https://git.kernel.org/stable/c/a66805c9b22caf4e42af7a616f6c6b83c90d1010 https://git.kernel.org/stable/c/955388e1d5d222c4101c596b536d41b91a8b212e https://git.kernel.org/stable/c/581302298524e9d77c4c44ff5156a6cd112227ae •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53122 – mptcp: cope racing subflow creation in mptcp_rcv_space_adjust
https://notcve.org/view.php?id=CVE-2024-53122
In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: creación de subflujo de ejecución en mptcp_rcv_space_adjust Los subflujos activos adicionales (es decir, creados por el administrador de rutas en el kernel) se incluyen en la lista de subflujos antes de iniciar 3whs. • https://git.kernel.org/stable/c/c76c6956566f974bac2470bd72fc22fb923e04a1 https://git.kernel.org/stable/c/0a9a182ea5c7bb0374e527130fd85024ace7279b https://git.kernel.org/stable/c/24995851d58c4a205ad0ffa7b2f21e479a9c8527 https://git.kernel.org/stable/c/ff825ab2f455299c0c7287550915a8878e2a66e0 https://git.kernel.org/stable/c/aad6412c63baa39dd813e81f16a14d976b3de2e8 https://git.kernel.org/stable/c/ce7356ae35943cc6494cc692e62d51a734062b7d •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53121 – net/mlx5: fs, lock FTE when checking if active
https://notcve.org/view.php?id=CVE-2024-53121
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. ... __ ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: fs, bloquear FTE al verificar si está activo Las confirmaciones a las que se hace referencia introdujeron un proceso de dos pasos para eliminar FTE: - Bloquear el FTE, eliminarlo del hardware, establecer la función de eliminación de hardware en NULL y desbloquear el FTE. - Bloquear el grupo de flujo principal, eliminar la copia de software del FTE y eliminarlo de la matriz x. • https://git.kernel.org/stable/c/718ce4d601dbf73b5dbe024a88c9e34168fe87f2 https://git.kernel.org/stable/c/0d568258f99f2076ab02e9234cbabbd43e12f30e https://git.kernel.org/stable/c/a508c74ceae2f5a4647f67c362126516d6404ed9 https://git.kernel.org/stable/c/5b47c2f47c2fe921681f4a4fe2790375e6c04cdd https://git.kernel.org/stable/c/bfba288f53192db08c68d4c568db9783fb9cb838 https://git.kernel.org/stable/c/094d1a2121cee1e85ab07d74388f94809dcfb5b9 https://git.kernel.org/stable/c/933ef0d17f012b653e9e6006e3f50c8d0238b5ed https://git.kernel.org/stable/c/9ca314419930f9135727e39d77e66262d •