Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: savage: Maneja el retorno de error cuando falla savagefb_check_var. El commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock es igual a cero") verifica el valor de pixclock para evitar división por error cero. Sin embargo, la función savagefb_probe no maneja la devolución de error de savagefb_check_var. Cuando pixclock es 0, provocará un error de división por cero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: corrige el punto muerto que raid5d() espera a que se borre MD_SB_CHANGE_PENDING Xiao informó que la prueba lvm2 lvconvert-raid-takeover.sh puede bloquearse con una pequeña posibilidad, la causa principal es exactamente lo mismo que el commit bed9e27baf52 ("Revertir "md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d") Sin embargo, Dan informó otro bloqueo después de eso, y Junxiao investigó el problema y descubrió que esto se debe a que la biografía conectada no puede emitir de raid5d(). La implementación actual en raid5d() tiene una dependencia extraña: 1) md_check_recovery() de raid5d() debe mantener 'reconfig_mutex' para borrar MD_SB_CHANGE_PENDING; 2) raid5d() maneja IO en un bucle muerto, hasta que se emiten todas las IO; 3) IO de raid5d() debe esperar a que se borre MD_SB_CHANGE_PENDING; Este comportamiento se introdujo antes de v2.6 y, como consecuencia, si otro contexto contiene 'reconfig_mutex' y md_check_recovery() no puede actualizar super_block, entonces raid5d() desperdiciará una CPU al 100% mediante el bucle muerto, hasta que 'reconfig_mutex' sea liberado. Consulte la implementación de raid1 y raid10, solucione este problema omitiendo el problema IO si MD_SB_CHANGE_PENDING todavía está configurado después de md_check_recovery(), el hilo del daemon se activará cuando se publique 'reconfig_mutex'. Mientras tanto, el problema de bloqueo también se solucionará.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hugetlb: no llame a vma_add_reservation cuando ENOMEM sysbot informó un splat [1] en __unmap_hugepage_range(). Esto se debe a que vma_needs_reservation() puede devolver -ENOMEM si allocate_file_region_entries() no puede asignar la estructura file_region para la reserva. Verifique eso y no llame a vma_add_reservation() si ese es el caso; de lo contrario, region_abort() y region_del() verán que no tenemos ningún file_regions. Si detectamos que vma_needs_reservation() devolvió -ENOMEM, borramos el indicador hugetlb_restore_reserve como si esta reserva todavía estuviera consumida, por lo que free_huge_folio() no incrementará el recuento de resv. [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: starfive: no liberar el búfer de pila Los datos de texto RSA utilizan un búfer de longitud variable asignado en la pila de software. Llamar a kfree provoca un comportamiento indefinido en operaciones posteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hwmon: deshacerse de devm Cuando tanto hwmon como hwmon drvdata (del cual depende hwmon) son recursos administrados por el dispositivo, la expectativa, al desvincular el dispositivo, es que hwmon publicarse antes que drvdata. Sin embargo, en i915 hay dos rutas de código independientes, que liberan drvdata o hwmon y cualquiera de ellas puede publicarse antes que la otra. Estas rutas de código (para desvincular el dispositivo) son las siguientes (consulte también el error al que se hace referencia a continuación): Seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 componente_unbind_all+0x8d/0xa0 componente_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915 ] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 dispositivo_release_driver_internal+0x19c/0x200 store+0x9c/0xb0 y seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_all +0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 Esto significa que en i915, si usa devm, no podemos garantizar que hwmon siempre se publicará antes que drvdata. Lo que significa que tenemos un uaf si se accede a hwmon sysfs cuando drvdata se lanzó pero hwmon no. La única forma de solucionar esto parece ser deshacerse de devm_ y liberar/liberar todo explícitamente durante la desvinculación del dispositivo. v2: Cambiar mensaje de confirmación y otros cambios menores de código v3: Limpieza de i915_hwmon_register en caso de error (Armin Wolf) v4: Eliminar posible advertencia del analizador estático (Rodrigo) Eliminar fetch_and_zero (Jani) v5: Restaurar la lógica anterior para el retorno de error ddat_gt->hwmon_dev (Andi )

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kdb: corrige el desbordamiento del búfer durante la finalización de tabulación Actualmente, cuando el usuario intenta completar el símbolo con la tecla Tab, kdb usará strncpy() para insertar el símbolo completado en el búfer de comando. Desafortunadamente, pasa el tamaño del búfer de origen en lugar del destino a strncpy() con resultados predeciblemente horribles. Lo más obvio es que si el búfer de comando ya está lleno pero cp, la posición del cursor, está en el medio del búfer, entonces escribiremos más allá del final del búfer proporcionado. Solucione este problema reemplazando las dudosas llamadas strncpy() con llamadas memmove()/memcpy() más comprobaciones explícitas de los límites para asegurarnos de que tenemos suficiente espacio antes de comenzar a mover los personajes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mc: corrige el recorrido del gráfico en media_pipeline_start El recorrido del gráfico intenta seguir todos los enlaces, incluso si no están entre pads. Esto provoca un bloqueo, por ejemplo, con un enlace MEDIA_LNK_FL_ANCILLARY_LINK. Solucione este problema permitiendo que la caminata continúe solo para los enlaces MEDIA_LNK_FL_DATA_LINK.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: WARN en la ventana vNMI + NMI si los NMI están completamente enmascarados Al solicitar una ventana NMI, WARN en la ventana de vNMI está habilitado si y solo si los NMI están realmente enmascarados, es decir, si la vCPU ya está manejando una NMI. La ABI de KVM para NMI que llegan simultáneamente (desde el punto de vista de KVM) es inyectar un NMI y esperar el otro. Cuando se usa vNMI, KVM suspende el segundo NMI simplemente configurando V_NMI_PENDING y deja que la CPU haga el resto (el hardware configura automáticamente V_NMI_BLOCKING cuando se inyecta un NMI). Sin embargo, si KVM no puede inyectar inmediatamente una NMI, por ejemplo, porque la vCPU está en una sombra STI o se está ejecutando con GIF=0, entonces KVM solicitará una ventana NMI y activará el WARN (pero seguirá funcionando correctamente). Es discutible si el caso GIF=0 tiene sentido o no, ya que la intención del comportamiento de KVM es proporcionar una funcionalidad lo más cercana posible al hardware real. Por ejemplo, si se envían dos NMI en rápida sucesión, la probabilidad de que ambos NMI lleguen a una sombra de STI es infinitamente baja en hardware real, pero significativamente mayor en un entorno virtual, por ejemplo, si la vCPU tiene prioridad en la sombra de STI. Para GIF=0, el argumento no es tan claro, porque la ventana donde dos NMI pueden colisionar es mucho mayor en el metal desnudo (aunque aún es pequeña). Dicho esto, KVM no debería tener un comportamiento divergente para el caso GIF=0 en función de si la compatibilidad con vNMI está habilitada o no. Y KVM ha permitido NMI simultáneas con GIF=0 durante más de una década, desde el commit 7460fb4a3400 ("KVM: Reparar NMI simultáneas"). Es decir, el manejo de GIF=0 de KVM no debe modificarse sin una *realmente* buena razón para hacerlo, y si se modifica el comportamiento de KVM, debe hacerse independientemente del soporte de vNMI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: v4l: async: Reinicializar correctamente la entrada del notificador al cancelar el registro Notifier_entry de un notificador no se reinicializa después de cancelar el registro del notificador. Esto lleva a que se dejen punteros colgando allí, así que use list_del_init() para devolver notifier_entry una lista vacía.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: corrige el abuso de matriz de longitud variable en btree_iter btree_iter se usa de dos maneras: ya sea asignado en la pila con un tamaño fijo MAX_BSETS, o desde un mempool con un tamaño dinámico basado en el conjunto de caché específico. Anteriormente, la estructura tenía una matriz de longitud fija de tamaño MAX_BSETS que estaba indexada fuera de los límites para los iteradores de tamaño dinámico, lo que provoca que UBSAN se queje. Este parche utiliza el mismo enfoque que en sort_iter de bcachefs y divide el iterador en un btree_iter con un miembro de matriz flexible y un btree_iter_stack que incorpora un btree_iter así como una matriz de datos de longitud fija.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfs: corrige la asignación del búfer de recuperación de registros para la corrección heredada de h_size. El commit a70f9fe52daa ("xfs: detecta y maneja el tamaño de iclog no válido establecido por mkfs") agregó una corrección para los valores incorrectos de h_size usados para el registro desmontaje inicial en versiones antiguas de xfsprogs. Posteriormente, el commit 0c771b99d6c9 ("xfs: cálculo de limpieza de bloques de encabezado LR") limpió el cálculo del búfer de recuperación de registros, pero dejó de usar el valor h_size fijo para dimensionar el búfer de recuperación de registros, lo que puede provocar un acceso fuera de los límites cuando el h_size incorrecto no proviene de la antigua herramienta mkfs, sino de un fuzzer. Solucione este problema abriendo la codificación xlog_logrec_hblks y teniendo en cuenta el h_size fijo para este cálculo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: corrige vmalloc que puede devolver nulo si se llama con __GFP_NOFAIL commit a421ef303008 ("mm: permitir asignaciones !GFP_KERNEL para kvmalloc") incluye soporte para __GFP_NOFAIL, pero presenta un conflicto con el commit dd544141b9eb ("vmalloc: retroceda cuando la tarea actual sea eliminada por OOM"). Un posible escenario es el siguiente: procesar-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer envía SIGKILL al proceso-a if (fatal_signal_pending(current)) break; --> devolver NULO; Para solucionar este problema, no marque fatal_signal_pending() en vm_area_alloc_pages() si __GFP_NOFAIL está configurado. Este problema ocurrió durante la PRUEBA DE OPLUS KASAN. A continuación se muestra parte del registro -> oom-killer envía señal para procesar [65731.222840] [T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/ uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Rastreo de llamadas: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] pila+0x18/0x24 [65731.259756] [ T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [ T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/ 0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454 ] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); pánico del kernel por desreferencia del puntero NULL. erofs supone que kvmalloc con __GFP_NOFAIL nunca devuelve NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] c [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [ 65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c