CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53127 – Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K"
https://notcve.org/view.php?id=CVE-2024-53127
In the Linux kernel, the following vulnerability has been resolved: Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K" The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - "swiotlb buffer is full" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "mmc: dw_mmc: Fix IDMAC operación con páginas mayores a 4K" el commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operación con páginas mayores a 4K") aumentó el max_req_size, incluso para páginas de 4K, causando varios problemas: - Arranque de pánico del kernel/rootfs desde una tarjeta SD en Rockchip RK3566 - Arranque de pánico del kernel/rootfs desde una tarjeta SD en StarFive JH7100 - "El búfer swiotlb está lleno" y corrupción de datos en StarFive JH7110 En esta etapa no se ha encontrado ninguna solución, por lo que probablemente sea mejor simplemente revertir el cambio. Esto revierte el commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890. • https://git.kernel.org/stable/c/32bd402f6760d57127d58a9888553b2db574bba6 https://git.kernel.org/stable/c/b9ee16a20d9976686185d7e59cd006c328b6a1e0 https://git.kernel.org/stable/c/2793f423893579b35dc1fc24dd7c1ce58fa0345a https://git.kernel.org/stable/c/9d715a234dd8f01af970b78ae2144a2fd3ead21c https://git.kernel.org/stable/c/373f8f5b087f010dddae3306a79c6fdd5c2f8953 https://git.kernel.org/stable/c/5b4bf3948875064a9adcda4b52b59e0520a8c576 https://git.kernel.org/stable/c/8396c793ffdf28bb8aee7cfe0891080f8cab7890 https://git.kernel.org/stable/c/5b1ef10f7d49f3320b0faa894204259e5 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53126 – vdpa: solidrun: Fix UB bug with devres
https://notcve.org/view.php?id=CVE-2024-53126
In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vdpa: solidrun: Fix UB bug with devres En psnet_open_pf_bar() y snet_open_vf_bar(), una cadena que luego se pasa a pcim_iomap_regions() se coloca en la pila. Ni pcim_iomap_regions() ni las funciones que llama copian esa cadena. Si la cadena se utiliza más tarde, esto, en consecuencia, provoca un comportamiento indefinido ya que el marco de la pila habrá desaparecido para entonces. • https://git.kernel.org/stable/c/51a8f9d7f587290944d6fc733d1f897091c63159 https://git.kernel.org/stable/c/d372dd09cfbf1324f54cbffd81fcaf6cdf3e608e https://git.kernel.org/stable/c/5bb287da2d2d5bb8f7376e223b02edb16998982e https://git.kernel.org/stable/c/0b364cf53b20204e92bac7c6ebd1ee7d3ec62931 •
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). Lo siguiente ocurre sin este parche: - r0 está marcado como no un subreg en (0); - w1 está marcado como subreg en (2); - el subreg_def de w1 es anulado en (3) por copy_register_state(); - w1 se lee en (5) pero mark_insn_zext() no marca (2) para extensión cero, porque el subreg_def de w1 no está configurado; - debido al indicador BPF_F_TEST_RND_HI32, el verificador inserta un valor aleatorio para los bits hi32 de (2) (marcado (r)); - este valor aleatorio se lee en (5). • 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> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? • 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. La causa principal es el mal manejo actual de la desconexión de la ejecución. Después de la confirmación criticada a continuación, sk_wait_data() puede regresar (con error) con el socket subyacente desconectado y un rcv_mss de cero. Detecte el error y regrese sin realizar ninguna operación adicional en el socket actual. • 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 •