Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/64s/interrupt: corrige la ejecución de salida de interrupción con un interruptor de mitigación de seguridad. Las opciones de mitigación de seguridad RFI y STF pueden invertir la condición de rama estática interrupt_exit_not_reentrant al mismo tiempo que el código de salida de interrupción que prueba esa rama. . La salida de interrupción prueba esta condición para configurar MSR[EE|RI] para la salida, luego nuevamente en el caso de que se encuentre pendiente una interrupción enmascarada, para recuperar el MSR para que la interrupción pueda reproducirse antes de intentar salir nuevamente. Si la condición cambia entre estas dos pruebas, el estado de la máscara suave MSR e irq se dañará, lo que generará advertencias y posibles fallas. Por ejemplo, si la rama es inicialmente verdadera y luego falsa, MSR[EE] será 0 pero PACA_IRQ_HARD_DIS estará clara y es posible que EE no se habilite, lo que generará advertencias en irq_64.c.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lib/generic-radix-tree.c: No se desborda en peek() Cuando comenzamos a distribuir nuevos números de inodos en la mayor parte del espacio de inodos de 64 bits, eso activó algunas esquinas. errores de casos, en particular algunos desbordamientos de enteros relacionados con el código del árbol de base. Ups.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vdpa: ifcvf: realice una limpieza adecuada si falla el inicio de IFCVF. ifcvf_mgmt_dev pierde memoria si no se libera antes de regresar. Se realiza una llamada para corregir la declaración de devolución para que no se pierda memoria. ifcvf_init_hw no se encarga de esto, por lo que es necesario hacerlo aquí.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: corrige la desreferencia del puntero null para restablecer el decodificador. No todos los decodificadores tienen una devolución de llamada de reinicio. La especificación CXL permite que un puente de host con un único puerto raíz no tenga decodificadores HDM explícitos. Actualmente, el controlador de región supone que no hay ninguno. Como tal, el núcleo CXL crea una instancia de decodificador de paso especial sin una devolución de llamada de confirmación/restablecimiento. Antes de este parche, la devolución de llamada ->reset() se llamaba incondicionalmente al llamar a cxl_region_decode_reset. Por lo tanto, una configuración con 1 puente de host, 1 puerto raíz y un dispositivo CXL tipo 3 conectado directamente o varios dispositivos CXL tipo 3 conectados a puertos descendentes de un conmutador puede provocar una desreferencia de puntero null. Antes de la solución, se observaba un fallo del kernel cuando destruíamos la región y se restablecía un decodificador de paso. El problema se puede reproducir como se muestra a continuación: 1) cree una región con una configuración CXL que incluya un HB con un único puerto raíz bajo el cual se conecta directamente un memdev. 2) destruir la región con cxl destroy-region regionX -f.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: single: corrige una posible desreferencia NULL. Se agregó la verificación de la "función" del puntero en pcs_set_mux(). pinmux_generic_get_function() puede devolver NULL y se eliminó la referencia al puntero "función" sin compararlo con NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: switch: soluciona una posible fuga de memoria en ice_add_adv_recipe(). Cuando ice_add_special_words() falla, el 'rm' no se libera, lo que provocará una pérdida de memoria. Solucione este problema yendo a la etiqueta 'err_unroll'. Compilación probada únicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: corrige una posible desreferencia del puntero null. En radeon_fp_native_mode(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd. También se verifica el estado de falla de drm_cvt_mode() en la otra ruta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrige la advertencia del kernel al enviar un mensaje SYN Al enviar un mensaje SYN, se observa este seguimiento de la pila del kernel: ... [ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550 . .. [ 13.398494] Seguimiento de llamadas: [ 13.398630] [ 13.398630] ? __alloc_skb+0xed/0x1a0 [13.398630] tipc_msg_build+0x12c/0x670 [tipc] [13.398630]? shmem_add_to_page_cache.isra.71+0x151/0x290 [13.398630] __tipc_sendmsg+0x2d1/0x710 [tipc] [13.398630] ? tipc_connect+0x1d9/0x230 [tipc] [13.398630]? __local_bh_enable_ip+0x37/0x80 [13.398630] tipc_connect+0x1d9/0x230 [tipc] [13.398630]? __sys_connect+0x9f/0xd0 [ 13.398630] __sys_connect+0x9f/0xd0 [ 13.398630] ? preempt_count_add+0x4d/0xa0 [13.398630]? fpregs_assert_state_consistent+0x22/0x50 [ 13.398630] __x64_sys_connect+0x16/0x20 [ 13.398630] do_syscall_64+0x42/0x90 [ 13.398630] Entry_SYSCALL_64_after_hwframe+0x63/0xcd Es porque la confirmación 41dad905e5a ("iov_iter: comprobaciones más sensatas para intentar copiar hacia/desde el iterador") ha introducido una verificación de cordura para copiar desde/hacia el iterador iov. La falta de dirección de copia desde el punto de vista del iterador conduciría a un seguimiento de la pila del kernel como se muestra arriba. Esta confirmación soluciona este problema al inicializar el iterador iov con la dirección de copia correcta al enviar SYN o ACK sin datos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: use un búfer de rebote para copiar skb->mark syzbot encontró que las compilaciones arm64 fallarían en sock_recv_mark() cuando CONFIG_HARDENED_USERCOPY=y x86 y powerpc no detectan el problema porque definen user_access_begin . Esto se manejará en un parche diferente, porque falta check_object_size(). Solo los datos de skb->cb[] se pueden copiar directamente hacia/desde el espacio de usuario, como se explica en la confirmación 79a8a642bf05 ("net: Lista blanca del campo skbuff_head_cache "cb") El informe de syzbot fue: copia de usuario: intento de exposición de la memoria del kernel detectado desde SLUB objeto 'skbuff_head_cache' (desplazamiento 168, tamaño 4)! ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/usercopy.c:102! Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 4410 Comm: syz-executor533 No contaminado 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 21/01/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: usercopy_abort+0x90/0x94 mm/usercopy.c:90 lr: usercopy_abort+0x90/0x94 mm/usercopy.c:90 sp: ffff80000fb9b9a0 x29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00 x26: 0000000000000014 5: ffff80000cf52000 x24: ffffc0000000000 x23: 05ffc00000000200 x22: ffffc000324bf80 x21: ffff0000c92fe1a8 x20: 0000000000000001 x19: 00000004 x18: 0000000000000000 x17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118 x14: ffff0000c6073400 x13: 00000000ffffffff x12: 073400 x11: ff808000081bbb4c x10: 0000000000000000 x9: 7b0572d7cc0ccf00 x8: 7b0572d7cc0ccf00 x7: ffff80000bf650d4 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: 0000000000000000 x2: ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c Rastreo de llamadas: usercopy_abort+0x90/0x94 mm/usercopy.c:90 __check_heap_object+0xa8/0x100 mm/slub.c:4761 check_heap_object mm/usercopy.c:196 __check_object _tamaño+0x208/0x6b8 mm/ usercopy.c:251 check_object_size include/linux/thread_info.h:199 [en línea] __copy_to_user include/linux/uaccess.h:115 [en línea] put_cmsg+0x408/0x464 net/core/scm.c:238 sock_recv_mark net/socket. c:975 [en línea] __sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984 sock_recv_cmsgs include/net/sock.h:2728 [en línea] paquete_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482 ____sys_recvmsg+0x1 10/0x3a0 ___sys_recvmsg net/socket.c:2737 [en línea] __sys_recvmsg+0x194/0x210 net/socket.c:2767 __do_sys_recvmsg net/socket.c:2777 [en línea] __se_sys_recvmsg net/socket.c:2774 [en línea] 64_sys_recvmsg+0x2c/0x3c net/socket.c:2774 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52 el0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall .c:142 do_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry -common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Código: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: openvswitch: corrige una posible pérdida de memoria en ovs_meter_cmd_set() old_meter debe estar libre después de desconectarlo, independientemente de si el nuevo medidor se conectó correctamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/usb: kalmia: No pasar act_len en la ruta de error usb_bulk_msg syzbot informó que act_len en kalmia_send_init_packet() no está inicializado al pasarlo a la primera ruta de error usb_bulk_msg. Jiri Pirko señaló que no tiene sentido pasarlo en la ruta de error y que el valor que se imprimiría en la segunda ruta de error sería el valor de act_len de la primera llamada a usb_bulk_msg.[1] Con esto en mente, simplemente no pasemos act_len a las rutas de error usb_bulk_msg. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL .Tetsuo-San notó que la confirmación f5d39b020809 ("freezer,sched: Rewrite core freezer logic") rompió call_usermodehelper_exec() para el caso KILLABLE. Específicamente, se pasó por alto que el segundo wait_for_completion() incondicional no era opcional y garantiza que la finalización en la pila no se utilice antes de salir del alcance.