Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: No establezca mddev private en NULL en raid0 pers->free En el proceso de detención normal, hace lo siguiente: do_md_stop | __md_stop (pers->free(); mddev->private=NULL) | md_free (free mddev) __md_stop establece mddev->private en NULL después de pers->free. El dispositivo raid se detendrá y la memoria mddev estará libre. Pero en reshape, no libera el mddev y mddev se seguirá usando en el nuevo raid. En reshape, primero establece mddev->private en new_pers y luego ejecuta old_pers->free(). Ahora raid0 establece mddev->private en NULL en raid0_free. El nuevo raid ya no puede funcionar. Entrará en pánico cuando desreferencia mddev->private debido a la desreferencia del puntero NULL. Puede entrar en pánico de esta manera: [63010.814972] ¡ERROR del kernel en drivers/md/raid10.c:928! [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1 [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020 [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10] [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246 [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000 [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800 [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000 [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200 [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003 [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000 [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0 [63010.927363] Call Trace: [63010.929822] ? bio_reset+0xe/0x40 [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10] [63010.938629] raid10_sync_request+0x756/0x1610 [raid10] [63010.943770] md_do_sync.cold+0x3e4/0x94c [63010.947698] md_thread+0xab/0x160 [63010.951024] ? md_write_inc+0x50/0x50 [63010.954688] kthread+0x149/0x170 [63010.957923] ? set_kthread_struct+0x40/0x40 [63010.962107] ret_from_fork+0x22/0x30 Eliminar el código que establece mddev->private en NULL en raid0 puede solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/page_owner: usar strscpy() en lugar de strlcpy() current->comm[] no es una cadena (no hay garantía de que haya un byte cero en ella). strlcpy(s1, s2, l) está llamando a strlen(s2), lo que podría provocar un acceso fuera de los límites, como informó syzbot: se detectó un desbordamiento de búfer en __fortify_strlen ------------[ corte aquí ]------------ ¡ERROR del kernel en lib/string_helpers.c:980! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 4087 Comm: dhcpcd-run-hooks Not tainted 5.18.0-rc3-syzkaller-01537-g20b87e7c29df #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:fortify_panic+0x18/0x1a lib/string_helpers.c:980 Code: 8c e8 c5 ba e1 fa e9 23 0f bf fa e8 0b 5d 8c f8 eb db 55 48 89 fd e8 e0 49 40 f8 48 89 ee 48 c7 c7 80 f5 26 8a e8 99 09 f1 ff <0f> 0b e8 ca 49 40 f8 48 8b 54 24 18 4c 89 f1 48 c7 c7 00 00 27 8a RSP: 0018:ffffc900000074a8 EFLAGS: 00010286 RAX: 000000000000002c RBX: ffff88801226b728 RCX: 0000000000000000 RDX: ffff8880198e0000 RSI: ffffffff81600458 RDI: fffff52000000e87 RBP: ffffffff89da2aa0 R08: 000000000000002c R09: 0000000000000000 R10: ffffffff815fae2e R11: 0000000000000000 R12: ffff88801226b700 R13: ffff8880198e0830 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5876ad6ff8 CR3: 000000001a48c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: __fortify_strlen include/linux/fortify-string.h:128 [inline] strlcpy include/linux/fortify-string.h:143 [inline] __set_page_owner_handle+0x2b1/0x3e0 mm/page_owner.c:171 __set_page_owner+0x3e/0x50 mm/page_owner.c:190 prep_new_page mm/page_alloc.c:2441 [inline] get_page_from_freelist+0xba2/0x3e00 mm/page_alloc.c:4182 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5408 alloc_pages+0x1aa/0x310 mm/mempolicy.c:2272 alloc_slab_page mm/slub.c:1799 [inline] allocate_slab+0x26c/0x3c0 mm/slub.c:1944 new_slab mm/slub.c:2004 [inline] ___slab_alloc+0x8df/0xf20 mm/slub.c:3005 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3092 slab_alloc_node mm/slub.c:3183 [inline] slab_alloc mm/slub.c:3225 [inline] __kmem_cache_alloc_lru mm/slub.c:3232 [inline] kmem_cache_alloc+0x360/0x3b0 mm/slub.c:3242 dst_alloc+0x146/0x1f0 net/core/dst.c:92

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Limpiar hash direct_functions en caso de fallos de registro Vemos el siguiente GPF cuando falla register_ftrace_direct: [ ] fallo de protección general, probablemente para dirección no canónica \ 0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [...] [ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70 [ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...] [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206 [ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b [ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0 [ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001 [ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0 [ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000 [ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000 [ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0 [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ ] Call Trace: [ ] [ ] register_ftrace_direct+0x54/0x290 [ ] ? render_sigset_t+0xa0/0xa0 [ ] bpf_trampoline_update+0x3f5/0x4a0 [ ] ? 0xffffffffa00a3000 [ ] bpf_trampoline_link_prog+0xa9/0x140 [ ] bpf_tracing_prog_attach+0x1dc/0x450 [ ] bpf_raw_tracepoint_open+0x9a/0x1e0 [ ] ? find_held_lock+0x2d/0x90 [ ] ? lock_release+0x150/0x430 [ ] __sys_bpf+0xbd6/0x2700 [ ] ? lock_is_held_type+0xd8/0x130 [ ] __x64_sys_bpf+0x1c/0x20 [ ] do_syscall_64+0x3a/0x80 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae [ ] RIP: 0033:0x7fa9421defa9 [ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...] [ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ ] RAX: ffffffffffffffda RBX: 00000000069d2480 RCX: 00007fa9421defa9 [ ] RDX: 0000000000000078 RSI: 00007ffed743bd80 RDI: 0000000000000011 [ ] RBP: 00007ffed743be00 R08: 0000000000bb7270 R09: 0000000000000000 [ ] R10: 00000000069da210 R11: 0000000000000246 R12: 0000000000000001 [ ] R13: 00007ffed743c4b0 R14: 00000000069d2480 R15: 0000000000000001 [ ] [ ] Modules linked in: klp_vm(OK) [ ] ---[ end trace 0000000000000000 ]--- One way to trigger this is: 1. load a livepatch that patches kernel function xxx; 2. run bpftrace -e 'kfunc:xxx {}', esto fallará (esperado por ahora); 3. repetir #2 => gpf. Esto se debe a que la entrada se agrega a direct_functions, pero no se elimina. Solucione esto eliminando la entrada de direct_functions cuando register_ftrace_direct falle. También elimine el último espacio final de ftrace.c, para que ya no tengamos que preocuparnos por eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/string_helpers: se ha corregido el problema de no añadir strarray a la lista de recursos del dispositivo. Se añade el strarray asignado a la lista de recursos del dispositivo. Esto es imprescindible para liberar automáticamente strarray cuando el dispositivo desaparece. Sin esta corrección, tenemos una pérdida de memoria en los pocos controladores que utilizan devm_kasprintf_strarray().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hfi1: Se corrigen posibles errores de desbordamiento de multiplicación de enteros Al multiplicar diferentes tipos, es posible que se produzca un desbordamiento incluso cuando se almacena el resultado en un tipo más grande. Esto se debe a que la conversión se realiza después de la multiplicación. Por lo tanto, es posible que se produzca un desbordamiento aritmético y, por lo tanto, un valor incorrecto. Corrija una instancia de esto en el cálculo del retraso entre paquetes. Solucione asegurándose de que uno de los operandos sea u64, lo que promoverá el otro a u64 y también garantizará que no haya desbordamiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: se corrige la doble liberación de io_acct_set bioset Ahora io_acct_set está asignado y libre en la personalidad. Elimine los códigos que liberan io_acct_set en md_free y md_stop.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: driver: base: fix UAF when driver_attach failed Cuando driver_attach(drv); falla, se libera driver_private. Pero se ha añadido al bus, lo que ha provocado un UAF. Para solucionarlo, debemos eliminarlo del bus cuando falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: ti: am65-cpsw-nuss: Se corrigen algunas fugas de refcount of_get_child_by_name() devuelve un puntero de nodo con refcount incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. am65_cpsw_init_cpts() y am65_cpsw_nuss_probe() no liberan el refcount en caso de error. Agregue of_node_put() faltante para evitar la fuga de refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: rzg2l_wdt: soluciona el problema de desbordamiento de 32 bits El valor de timer_cycle_us puede ser 0 debido al desbordamiento de 32 bits. Por ejemplo: si asignamos el valor del contador "0xfff" para calcular maxval. Este parche soluciona este problema añadiendo ULL a 1024, de modo que se promueva a 64 bits. Este parche también soluciona el mensaje de advertencia, 'watchdog: Invalid min and max timeout values, resetting to 0!'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubi: ubi_create_volume: Se corrige el problema de use-after-free cuando falla la creación del volumen Hay un problema de use-after-free para 'eba_tbl' en la ruta de gestión de errores de ubi_create_volume(): ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Libera 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Arréglalo eliminando la liberación redundante de 'eba_tbl'. Obtén un reproductor en [Enlace].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: usbip: se corrige una pérdida de recuento de referencias en stub_probe(). Se llama a usb_get_dev() en stub_device_alloc(). Cuando stub_probe() falla después de eso, se debe llamar a usb_put_dev() para liberar la referencia. Corrija esto moviendo usb_put_dev() a la gestión de la ruta de error sdev_free. Encuentre esto mediante la revisión del código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: macsec: se corrige el error UAF para real_dev Crea un nuevo dispositivo macsec pero no obtiene la referencia a real_dev. Esto no puede garantizar que real_dev se libere después de macsec. Esto activará el error UAF para real_dev de la siguiente manera: ==================================================================== ERROR: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327 After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.