Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: core: borrando el búfer circular antes de anularlo. El búfer circular se anula en uart_tty_port_shutdown() bajo el bloqueo de giro. Sin embargo, el PM u otras devoluciones de llamada basadas en temporizadores aún pueden activarse después de este evento sin saber que el puntero del búfer no es válido. Dado que el código de serie es un poco inconsistente al verificar el estado del búfer (algunos se basan en las posiciones de cabecera y cola, otros en el puntero del búfer), es mejor tener ambos alineados, es decir, que el puntero del búfer sea NULL y las posiciones de cabecera y cola sean lo mismo, lo que significa que está vacío. Esto evitará llamadas asincrónicas para desreferenciar el puntero NULL como se informó recientemente en el caso 8250: ERROR: desreferencia del puntero NULL del kernel, dirección: 00000cf5 Cola de trabajo: pm pm_runtime_work EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809). . serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) __start_tx (drivers/tty/serial/8250/8250_port.c:1551) serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654) serial_port_runtime_suspend ( incluir/linux/serial_core.h:667 controladores/tty/serial/serial_port.c:63) __rpm_callback (drivers/base/power/runtime.c:393)? serial_port_remove (drivers/tty/serial/serial_port.c:50) rpm_suspend (drivers/base/power/runtime.c:447) El cambio propuesto evitará que se llame a ->start_tx() durante la suspensión al cerrar el puerto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: serial/pmac_zilog: eliminar la mitigación defectuosa para rx irq Flood La mitigación tenía como objetivo detener irq por completo. Esto puede ser mejor que un bloqueo duro, pero resulta que de todos modos se bloquea si estás usando pmac_zilog como consola serie: ttyPZ0: pmz: rx irq Flood ! ERROR: recursión de spinlock en CPU#0, swapper/0 Esto se debe a que la llamada pr_err() en pmz_receive_chars() da como resultado que pmz_console_write() intente bloquear un spinlock ya bloqueado en pmz_interrupt(). Con CONFIG_DEBUG_SPINLOCK=y, esto produce un error fatal. El spinlock en cuestión es el de la estructura uart_port. Incluso cuando no es fatal, la función de recepción del puerto serie deja de funcionar. Además, el límite de iteración no funciona bien con QEMU, como se puede ver en el informe de error vinculado a continuación. Una búsqueda en la web de otros informes del mensaje de error "pmz: rx irq Flood" no produjo nada. Así que no creo que este código ya sea necesario. Retírelo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc2: host: solucionó el problema de desreferencia en el flujo de finalización de DDMA. Se solucionó el problema de desreferencia variable en el flujo de finalización de DDMA.

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: Speakup: Evitar crash en palabras muy largas En caso de que una consola esté configurada muy grande y contenga una palabra muy larga (>256 caracteres), tenemos que detenernos antes de la longitud de la palabra. búfer de palabras.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/xe: corrija la fuga de bo en intel_fb_bo_framebuffer_init. Agregue un bo sin referencia en la ruta del error, para evitar que se filtre una referencia de bo. Devuelve 0 en caso de éxito para aclarar la ruta del éxito. (cereza escogida del compromiso a2f3d731be3893e730417ae3190760fcaffdf549)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: corrige la pérdida de memoria en el error create_process. Corrige la pérdida de memoria debido a una referencia mmget filtrada en una ruta de código de manejo de errores que se activa al intentar crear procesos KFD mientras se reinicia la GPU. Está en proceso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/memory-failure: corrige el interbloqueo cuando Hugetlb_optimize_vmemmap está habilitado Cuando hice una prueba dura sin conexión con páginas de Hugetlb, se produce el siguiente interbloqueo: ============ ========================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.8 .0-11409-gf6cef5f8c37f #1 No contaminado ---------------------------------------- -------------- bash/46904 está intentando adquirir el bloqueo: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, en: static_key_slow_dec+0x16/0x60 pero la tarea está ya mantiene el bloqueo: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, en: zone_pcp_disable+0x16/0x40 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/ 0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 Bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 t_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge _página+0x211/0x260 __página_handle_poison+0x45/ 0xc0 error_de_memoria+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entrada_SYSCALL_6 4_after_hwframe+0x6d/0x75 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- bloqueo(pcp_batch_high_lock); bloquear(cpu_hotplug_lock); bloquear(pcp_batch_high_lock); rlock(cpu_hotplug_lock); *** DEADLOCK *** 5 bloqueos retenidos por bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, en: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of ->mutex){+.+.}-{3:3}, en: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, en : kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, en: Memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3: 3}, en: zone_pcp_disable+0x16/0x40 seguimiento de pila: CPU: 10 PID: 46904 Comm: bash Kdump: cargado No contaminado 6.8.0-11409-gf6cef5f8c37f #1 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus _read_lock+0x2a /0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 Memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0 xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca /0x1e0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Código: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 : 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007ffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00 En resumen, La siguiente escena rompe el ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: hibernación: corrige el error de traducción de nivel 3 en swsusp_save() En máquinas arm64, swsusp_save() falla si intenta acceder a los rangos de memoria MEMBLOCK_NOMAP. Esto se puede reproducir en QEMU usando UEFI al arrancar con rodata=off debug_pagealloc=off y CONFIG_KFENCE=n: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffff8000000000 Información de cancelación de memoria: ESR = 0x0000000096000007 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: fallo de traducción de nivel 3 Información de cancelación de datos: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 pgtable de intercambio: páginas de 4k, VA de 39 bits, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff 9803, pud=180000217fff9803, pmd =180000217fff8803, pte=0000000000000000 Error interno: Ups: 0000000096000007 [#1] Error interno de SMP: Ups: 0000000096000007 [#1] Módulos SMP vinculados en: xt_multiport ipt_REJECT nf_reject_ipv4 x t_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath lineal amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep No contaminado 6.6.2 + #76 Versión de origen: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Nombre del hardware: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 19/01/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: swsusp_save+0x280/0x538 lr: swsusp_save+0x280/0x538 sp: ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20 : ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 00000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9: fffffc08193f0d0 x8: 00000000000bffe8 x7: c 0000000ffff7fff x6: 0000000000000001 x5: fffffa0fff09dc8 x4: 0000000000000000 x3: 0000000000000027 x2: 0000000000000000 x1: 0000000000000000 x0: 000000000000004e Rastreo de llamadas: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 bernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24 El motivo es swsusp_save( ) -> copy_data_pages() -> page_is_saveable() -> kernel_page_present() suponiendo que una página siempre está presente cuando can_set_direct_map() es falsa (todos rodata_full, debug_pagealloc_enabled() y arm64_kfence_can_set_direct_map() son falsos), independientemente de los rangos de MEMBLOCK_NOMAP. Estas regiones MEMBLOCK_NOMAP no deben guardarse durante la hibernación. Este problema se introdujo por cambios en la lógica pfn_valid() en el commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplifica pfn_valid()"). Al igual que en otras arquitecturas, elimine la verificación !can_set_direct_map() en kernel_page_present() para que page_is_savable() omita dichas páginas. [catalin.marinas@arm.com: mensaje de confirmación de reelaboración]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/mmu: Proteger contra escritura los SPTE L2 en la MMU TDP al borrar el estado sucio. Verifique kvm_mmu_page_ad_need_write_protect() cuando decida si desea proteger contra escritura o borrar los bits D en los SPTE de la MMU TDP. , de modo que la MMU TDP tenga en cuenta cualquier motivo específico de la función para deshabilitar el registro sucio de bits D. Específicamente, los SPTE de TDP MMU deben estar protegidos contra escritura cuando la TDP MMU se utiliza para ejecutar un L2 (es decir, L1 tiene EPT deshabilitado) y PML está habilitado. KVM siempre desactiva PML cuando se ejecuta L2, incluso cuando los GPA L1 y L2 están en algún dominio, por lo que si no se protegen contra escritura los SPTE TDP MMU, las escrituras realizadas por L2 no se reflejarán en el registro sucio. [sean: masajear el registro corto y el registro de cambios, modificar el formato de operación ternario]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: x86/mmu: x86: no desborde lpage_info al verificar los atributos. Corrija KVM_SET_MEMORY_ATTRIBUTES para no desbordar la matriz lpage_info y activar KASAN splat, como se ve en la autoprueba private_mem_conversions_test. Cuando los atributos de memoria se configuran en un rango GFN, ese rango tendrá propiedades específicas aplicadas al TDP. No se puede utilizar una página enorme cuando los atributos son inconsistentes, por lo que están deshabilitados para aquellas páginas enormes específicas. Por razones internas de KVM, tampoco se permite que páginas grandes abarquen ranuras de memoria adyacentes, independientemente de si la memoria de respaldo podría asignarse como enorme. Qué GFN admite qué tamaños de página enormes se rastrea mediante una serie de matrices 'lpage_info' en el memslot, de estructuras 'kvm_lpage_info'. Cada índice de lpage_info contiene una matriz asignada por vmalloc para un tamaño de página compatible específico. kvm_lpage_info indica si se admite una página enorme específica (GFN y tamaño de página) en la ranura de memoria. Estas matrices incluyen índices para páginas grandes de cabecera y cola no alineadas. Para evitar que páginas grandes abarquen ranuras de memoria adyacentes, se incrementa el recuento en head y tail kvm_lpage_info cuando se asigna la ranura de memoria, pero no permitir páginas grandes para memoria que tenga atributos mixtos debe hacerse de una manera más complicada. Durante KVM_SET_MEMORY_ATTRIBUTES ioctl, KVM actualiza lpage_info para cada ranura de memoria en el rango que tiene atributos que no coinciden. KVM hace esto una ranura de memoria a la vez y marca un bit especial, KVM_LPAGE_MIXED_FLAG, en kvm_lpage_info para cualquier página grande. Este bit es esencialmente un recuento elevado permanentemente. Por lo tanto, las páginas grandes no se asignarán para GFN en ese tamaño de página si el recuento es elevado en cualquier caso: una página principal o final enorme no alineada con la ranura de memoria o si KVM_LPAGE_MIXED_FLAG está configurado porque tiene atributos mixtos. Para determinar si una página enorme tiene atributos consistentes, la operación KVM_SET_MEMORY_ATTRIBUTES verifica una matriz x para asegurarse de que tenga consistentemente el atributo entrante. Dado que las páginas grandes de nivel 1 están alineadas con las páginas grandes de nivel, se emplea una optimización. Siempre que se verifiquen primero las páginas grandes de nivel - 1, puede simplemente verificarlas y asumir que si cada página enorme de nivel - 1 contenida dentro de la página enorme de tamaño de nivel no está mezclada, entonces la página enorme de tamaño de nivel no está mezclada. Esta optimización ocurre en el ayudante Hugepage_has_attrs(). Desafortunadamente, aunque la matriz kvm_lpage_info que representa el tamaño de página 'nivel' contendrá una entrada para una página final no alineada de nivel de tamaño, la matriz para el nivel - 1 no contendrá una entrada para cada GFN en el nivel de tamaño de página. La matriz de nivel 1 solo contendrá un índice para cualquier región no alineada cubierta por el tamaño de página enorme de nivel 1, que puede ser una región más pequeña. Entonces, esto hace que la optimización desborde el nivel - 1 kvm_lpage_info y realice una lectura vmalloc fuera de los límites. En algunos casos de páginas principales y finales donde podría ocurrir un desbordamiento, las personas que llaman omiten la operación por completo ya que KVM_LPAGE_MIXED_FLAG no es necesario para evitar páginas grandes como se analizó anteriormente. Pero para las ranuras de memoria que son más pequeñas que el tamaño de página de 1 GB, llama a hugepage_has_attrs(). En este caso, la página enorme es tanto la página principal como la final. --truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/pmu: deshabilitar el soporte para PEBS adaptativos. Eliminar el soporte para virtualizar PEBS adaptativos, ya que la implementación de KVM tiene una arquitectura rota sin un camino obvio/fácil a seguir, y porque exponer PEBS adaptativos puede filtrar los LBR del host al huésped, es decir, puede filtrar las direcciones del kernel del host al huésped. El error número 1 es que KVM no tiene en cuenta los 32 bits superiores de IA32_FIXED_CTR_CTRL cuando (re)programa contadores fijos, por ejemplo, fix_ctrl_field() elimina los bits superiores, reprogram_fixed_counters() almacena variables locales como u8 y también trunca los bits superiores, etc. El error número 2 es que, debido a que KVM _siempre_ establece precision_ip en un valor distinto de cero para eventos PEBS, perf _siempre_ generará un registro adaptativo, incluso si el invitado solicitó un registro básico. Tenga en cuenta que KVM también habilitará PEBS adaptativo en *contador* individual, incluso si PEBS adaptativo no está expuesto al invitado, pero esto es benigno ya que se garantiza que MSR_PEBS_DATA_CFG será cero, es decir, el invitado solo verá registros básicos. El error número 3 está en rendimiento. intel_pmu_disable_fixed() tampoco borra los bits superiores, es decir, deja ICL_FIXED_0_ADAPTIVE configurado, e intel_pmu_enable_fixed() efectivamente tampoco borra ICL_FIXED_0_ADAPTIVE. Es decir, perf _siempre_ habilita contadores ADAPTIVOS, independientemente de lo que solicite KVM. El error número 4 es que los PEBS adaptables *podrían* omitir efectivamente los filtros de eventos establecidos por el host, ya que el "Grupo de información de acceso a memoria actualizado" registra información que podría no estar permitida por el espacio de usuario a través de KVM_SET_PMU_EVENT_FILTER. El error número 5 es que KVM no garantiza que los MSR LBR mantengan valores de invitado (o al menos ceros) al ingresar a una vCPU con PEBS adaptable, lo que permite al invitado leer los LBR del host, es decir, los RIP/direcciones del host, al habilitar las "Entradas LBR". registros. Deshabilite el soporte PEBS adaptable como solución inmediata debido a la gravedad de la fuga de LBR en particular, y porque corregir todos los errores no será trivial, por ejemplo, no es adecuado para realizar backporting a núcleos estables. ¡Nota! Esto interrumpirá la migración en vivo, pero tratar de hacer que KVM funcione bien con la migración en vivo sería bastante complicado, no se garantizaría que funcione (es decir, KVM aún podría matar/confundir al invitado) y no está claro si hay alguno disponible públicamente. Los VMM que admiten PEBS adaptables, y mucho menos migran en vivo las máquinas virtuales que admiten PEBS adaptables; por ejemplo, QEMU no admite PEBS de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: init/main.c: soluciona un posible desbordamiento de memoria de static_command_line Asignamos memoria de tamaño 'xlen + strlen(boot_command_line) + 1' para static_command_line, pero las cadenas copiadas en static_command_line son extra_command_line y command_line, en lugar de extra_command_line y boot_command_line. Cuando strlen(command_line) > strlen(boot_command_line), static_command_line se desbordará. Este parche simplemente recupera strlen(command_line) que no se consolidó con strlen(boot_command_line) en el commit f5c7310ac73e ("init/main: agregue comprobaciones para el valor de retorno de memblock_alloc*()")