Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: Se corrige la lectura fuera de los límites en la configuración de LDT syscall_stub_data() espera que el parámetro data_count sea el número de longs, no bytes. ===================================================================== ERROR: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp: se corrige la pérdida del controlador de reinicio en los errores de sondeo Asegúrese de liberar el controlador de reinicio de carril en caso de un error de sondeo tardío (por ejemplo, aplazamiento de sondeo). Tenga en cuenta que debido a que el controlador de reinicio se define en devicetree en los nodos secundarios "lane", devm_reset_control_get_exclusive() no se puede usar directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp: corrige pérdida de struct clk en errores de sonda Asegúrese de liberar la referencia del reloj de la tubería en caso de un error de sonda tardío (por ejemplo, aplazamiento de la sonda).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Reemplazar list_for_each_entry_safe() si se usa giveback La macro list_for_each_entry_safe() guarda el elemento actual (n) y el elemento posterior (n+1), de modo que n se pueda eliminar de forma segura sin dañar la lista. Sin embargo, al recorrer la lista y eliminar elementos usando gadget giveback, el bloqueo DWC3 se libera brevemente, lo que permite que se ejecuten otras rutinas. Existe una situación en la que, mientras se eliminan elementos de la lista cancelada usando dwc3_gadget_ep_cleanup_cancelled_requests(), la rutina de desactivación de pullup se ejecuta en paralelo (debido a la desvinculación de UDC). A medida que la rutina de limpieza elimina n, y la desactivación de pullup elimina n+1, una vez que la limpieza retoma el bloqueo DWC3, hace referencia a una solicitud que ya fue eliminada/gestionada. Con la depuración de lista habilitada, esto genera un pánico. Asegúrese de que todas las instancias de la macro se reemplacen donde se use la devolución de gadgets. Ejemplo de pila de llamadas: Thread#1: __dwc3_gadget_ep_set_halt() - CLEAR HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list] ->spin_unlock ->Thread#2 executes ... ->dwc3_gadget_giveback(n+1) ->Already removed! Thread#2: dwc3_gadget_pullup() ->waiting for dwc3 spin_lock ... ->Thread#1 released lock ->dwc3_stop_active_transfers() ->dwc3_remove_requests() ->fetches n+1 item from cancelled_list (n removed by Thread#1) ->dwc3_gadget_giveback() ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list] ->spin_unlock

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: goldfish: Use tty_port_destroy() para destruir el puerto En goldfish_tty_probe(), el puerto inicializado a través de tty_port_init() debe destruirse en las rutas de error. En goldfish_tty_remove(), qtty->port también debe destruirse o, de lo contrario, podría perder recursos. Corrija lo anterior llamando a tty_port_destroy().

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.