CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26677 – rxrpc: Fix delayed ACKs to not set the reference serial number
https://notcve.org/view.php?id=CVE-2024-26677
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrige los ACK retrasados para no establecer el número de serie de referencia. Se corrige la construcción de los ACK retrasados para no establecer el número de serie de referencia, ya que no se pueden usar como referencia RTT. • https://git.kernel.org/stable/c/17926a79320afa9b95df6b977b40cca6d8713cea https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2 https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26676 – af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
https://notcve.org/view.php?id=CVE-2024-26676
In the Linux kernel, the following vulnerability has been resolved: af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. syzbot reported a warning [0] in __unix_gc() with a repro, which creates a socketpair and sends one socket's fd to itself using the peer. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 This forms a self-cyclic reference that GC should finally untangle but does not due to lack of MSG_OOB handling, resulting in memory leak. Recently, commit 11498715f266 ("af_unix: Remove io_uring code for GC.") removed io_uring's dead code in GC and revealed the problem. The code was executed at the final stage of GC and unconditionally moved all GC candidates from gc_candidates to gc_inflight_list. That papered over the reported problem by always making the following WARN_ON_ONCE(!list_empty(&gc_candidates)) false. The problem has been there since commit 2aab4b969002 ("af_unix: fix struct pid leaks in OOB support") added full scm support for MSG_OOB while fixing another bug. To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb if the socket still exists in gc_candidates after purging collected skb. Then, we need to set NULL to oob_skb before calling kfree_skb() because it calls last fput() and triggers unix_release_sock(), where we call duplicate kfree_skb(u->oob_skb) if not NULL. Note that the leaked socket remained being linked to a global list, so kmemleak also could not detect it. We need to check /proc/net/protocol to notice the unfreed socket. [0]: WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Modules linked in: CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: events_unbound __unix_gc RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8 RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30 RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66 R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000 R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> process_one_work+0x889/0x15e0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Llame a kfree_skb() para unix_(sk)->oob_skb muerto en GC. syzbot informó una advertencia [0] en __unix_gc() con una reproducción, que crea un par de sockets y se envía el fd de un socket a sí mismo utilizando el par. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 Esto forma una referencia autocíclica ese GC finalmente debería desenredarse, pero no lo hace debido a la falta de manejo de MSG_OOB, lo que resulta en una pérdida de memoria. Recientemente, el commit 11498715f266 ("af_unix: Eliminar el código io_uring para GC.") eliminó el código inactivo de io_uring en GC y reveló el problema. El código se ejecutó en la etapa final de GC y movió incondicionalmente todos los candidatos de GC de gc_candidates a gc_inflight_list. • https://git.kernel.org/stable/c/f3969427fb06a2c3cd6efd7faab63505cfa76e76 https://git.kernel.org/stable/c/ac1968ac399205fda9ee3b18f7de7416cb3a5d0d https://git.kernel.org/stable/c/2aab4b96900272885bc157f8b236abf1cdc02e08 https://git.kernel.org/stable/c/a59d6306263c38e5c0592ea4451ca26a0778c947 https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668 https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276 https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb43 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26675 – ppp_async: limit MRU to 64K
https://notcve.org/view.php?id=CVE-2024-26675
In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ppp_async: limitar MRU a 64K syzbot activó una advertencia [1] en __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem solucionó un problema similar en el commit c0a2a1b0d631 ("ppp: limite MRU a 64K") Adopte la misma verificación de cordura para ppp_async_ioctl(PPPIOCSMRU) [1]: ADVERTENCIA: CPU: 1 PID: 11 en mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Módulos vinculados en: CPU: 1 PID: 11 Comm: kworker/u4:0 No contaminado 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: events_unbound flux_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp: ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000 939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff8000939671 20 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 00000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9: 0000000000000001 x8: ffff800091c 91000 x7: 0000000000000000 x6: 000000000000003f x5: 00000000ffffffff x4: 0000000000000000 x3: 00000000000000020 x2: 0000000000000008 x1: 0000000000000000 x0: ffff8000939675e0 Rastreo de llamadas: __alloc_pages+0x308/ 0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [en línea] alloc_pages_node include/linux/gfp.h:261 [en línea] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub .c:3969 [en línea] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0x b8 /0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [en línea] dev_alloc_skb include/linux/skbuff.h:3248 [en línea] ppp_async_input drivers/net/ppp/ppp_async.c:863 [ en línea] ppp_asynctty_receive+0x588/0x186c controladores/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c controladores/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac controladores/tty/tty_port.c:37 recibir_buf controladores /tty /tty_buffer.c:444 [en línea] Flush_to_ldisc+0x284/0x6e4 controladores/tty/tty_buffer.c:494 Process_one_work+0x694/0x1204 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] trabajador_thread+0x938/ 0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982 https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3 https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16 https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719 https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26674 – x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups
https://notcve.org/view.php?id=CVE-2024-26674
In the Linux kernel, the following vulnerability has been resolved: x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups During memory error injection test on kernels >= v6.4, the kernel panics like below. However, this issue couldn't be reproduced on kernels <= v6.3. mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134 mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20} mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86 mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Kernel panic - not syncing: Fatal local machine check The MCA code can recover from an in-kernel #MC if the fixup type is EX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to access userspace memory. However, if the fixup type is EX_TYPE_DEFAULT the only thing that is raised for an in-kernel #MC is a panic. ex_handler_uaccess() would warn if users gave a non-canonical addresses (with bit 63 clear) to {get, put}_user(), which was unexpected. Therefore, commit b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()") replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user() fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic. Commit 6014bc27561f ("x86-64: make access_ok() independent of LAM") added the check gp_fault_address_ok() right before the WARN_ONCE() in ex_handler_uaccess() to not warn about non-canonical user addresses due to LAM. With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user() exception fixups in order to be able to handle in-kernel MCEs correctly again. [ bp: Massage commit message. ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/lib: vuelva a _ASM_EXTABLE_UA() para reparaciones de {get,put}_user() Durante la prueba de inyección de errores de memoria en kernels >= v6.4, el kernel entra en pánico como se muestra a continuación. Sin embargo, este problema no se pudo reproducir en kernels <= v6.3. mce: [Error de hardware]: CPU 296: Excepción de verificación de la máquina: f Banco 1: bd80000000100134 mce: [Error de hardware]: RIP 10: {__get_user_nocheck_4+0x6/0x20} mce: [Error de hardware]: TSC 411a93533ed ADDR 346a87300 40 MISC 86 mce: [Error de hardware]: PROCESADOR 0:a06d0 HORA 1706000767 SOCKET 1 APIC 211 microcódigo 80001490 mce: [Error de hardware]: Ejecute lo anterior a través de 'mcelog --ascii' mce: [Error de hardware]: Verificación de la máquina: Carga de datos en un área irrecuperable del kernel Pánico del kernel - no se sincroniza: verificación fatal de la máquina local El código MCA se puede recuperar de un #MC en el kernel si el tipo de reparación es EX_TYPE_UACCESS, lo que indica explícitamente que el kernel está intentando acceder a la memoria del espacio de usuario. • https://git.kernel.org/stable/c/b19b74bc99b1501a550f4448d04d59b946dc617a https://git.kernel.org/stable/c/2aed1b6c33afd8599d01c6532bbecb829480a674 https://git.kernel.org/stable/c/2da241c5ed78d0978228a1150735539fe1a60eca https://git.kernel.org/stable/c/8eed4e00a370b37b4e5985ed983dccedd555ea9d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52636 – libceph: just wait for more data to be available on the socket
https://notcve.org/view.php?id=CVE-2023-52636
In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket. Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data(). The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client. The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let's reuse cursor->total_resid. Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data. • https://git.kernel.org/stable/c/d396f89db39a2f259e2125ca43b4c31bb65afcad https://git.kernel.org/stable/c/da9c33a70f095d5d55c36d0bfeba969e31de08ae https://git.kernel.org/stable/c/bd9442e553ab8bf74b8be3b3c0a43bf4af4dc9b8 https://git.kernel.org/stable/c/8e46a2d068c92a905d01cbb018b00d66991585ab •