Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rose: corrección de punteros vecinos colgantes en rose_rt_device_down(). Hay dos errores en rose_rt_device_down() que pueden causar un use-after-free: 1. El límite del bucle `t->count` se modifica dentro del bucle, lo que puede provocar que el bucle termine antes de tiempo y se pierdan algunas entradas. 2. Al eliminar una entrada de la matriz de vecinos, las entradas posteriores se mueven hacia arriba para llenar el espacio vacío, pero el índice del bucle `i` aún se incrementa, lo que hace que se omita la siguiente entrada. Por ejemplo, si un nodo tiene tres vecinos (A, A, B) con count=3 y se está eliminando A, no se comprueba el segundo A. i=0: (A, A, B) -> (A, B) con count=2 ^ comprobado i=1: (A, B) -> (A, B) con count=2 ^ comprobado (¡B, no A!) i=2: (no ocurre porque i < count es falso) Esto deja la segunda A en el array con count=2, pero la estructura rose_neigh se ha liberado. El código que accede a estas entradas asume que las primeras entradas de `count` son punteros válidos, lo que provoca un use-after-free al acceder al puntero colgante. Solucione ambos problemas iterando sobre el array en orden inverso con un límite de bucle fijo. Esto garantiza que se examinen todas las entradas y que la eliminación de una entrada no afecte a las iteraciones posteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: verificar la validez de "num_cpu" desde el espacio del usuario. El número máximo de CPU admitido es EIOINTC_ROUTE_MAX_VCPUS sobre irqchip EIOINTC, aquí agregue validación sobre el número de CPU para evitar el desbordamiento del puntero de la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: Evitar el desbordamiento con el índice de la matriz. La variable índice se modifica y se reutiliza como índice de la matriz al modificar el registro EIOINTC_ENABLE. Se producirá un problema de desbordamiento del índice de la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: tps6594-pfsm: Se ha añadido una comprobación de puntero nulo en tps6594_pfsm_probe(). El valor devuelto, pfsm->miscdev.name, desde devm_kasprintf() podría ser nulo. Se ha añadido una comprobación de puntero para evitar posibles desreferencias de punteros nulos. Esto es similar a la corrección en el commit 3027e7b15b02 ("ice: Se corrigen algunos problemas de desreferencia de puntero nulo en ice_ptp.c"). Nuestra herramienta de análisis estático ha detectado este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el error al reconstruir el árbol de espacio libre utilizando múltiples transacciones Si estamos reconstruyendo un árbol de espacio libre, mientras modificamos el árbol de espacio libre, es posible que necesitemos asignar un nuevo grupo de bloques de metadatos. Si terminamos utilizando múltiples transacciones para la reconstrucción, cuando llamamos a btrfs_end_transaction() ingresamos btrfs_create_pending_block_groups() que llama a add_block_group_free_space() para agregar elementos al árbol de espacio libre para el grupo de bloques. Luego, más tarde durante la reconstrucción del árbol de espacio libre, en btrfs_rebuild_free_space_tree(), podemos encontrar dichos nuevos grupos de bloques y llamar a populate_free_space_tree() para ellos, lo que falla con -EEXIST porque ya hay elementos en el árbol de espacio libre. Luego abortamos la transacción con -EEXIST en btrfs_rebuild_free_space_tree(). Tenga en cuenta que decimos "puede encontrar" los nuevos grupos de bloques porque se puede insertar un nuevo grupo de bloques en el árbol de grupos de bloques, que está siendo iterado por el proceso de reconstrucción, antes o después del nodo actual en el que se encuentra actualmente el proceso de reconstrucción. Syzbot informó recientemente de un caso similar que produce un seguimiento como el siguiente: ------------[ cut here ]------------ BTRFS: Transaction aborted (error -17) WARNING: CPU: 1 PID: 7626 at fs/btrfs/free-space-tree.c:1341 btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 Modules linked in: CPU: 1 UID: 0 PID: 7626 Comm: syz.2.25 Not tainted 6.15.0-rc7-syzkaller-00085-gd7fa1af5b33e-dirty #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 lr : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 sp : ffff80009c4f7740 x29: ffff80009c4f77b0 x28: ffff0000d4c3f400 x27: 0000000000000000 x26: dfff800000000000 x25: ffff70001389eee8 x24: 0000000000000003 x23: 1fffe000182b6e7b x22: 0000000000000000 x21: ffff0000c15b73d8 x20: 00000000ffffffef x19: ffff0000c15b7378 x18: 1fffe0003386f276 x17: ffff80008f31e000 x16: ffff80008adbe98c x15: 0000000000000001 x14: 1fffe0001b281550 x13: 0000000000000000 x12: 0000000000000000 x11: ffff60001b281551 x10: 0000000000000003 x9 : 1c8922000a902c00 x8 : 1c8922000a902c00 x7 : ffff800080485878 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008047843c x2 : 0000000000000001 x1 : ffff80008b3ebc40 x0 : 0000000000000001 Call trace: btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 (P) btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 irq event stamp: 330 hardirqs last enabled at (329): [] raw_spin_rq_unlock_irq kernel/sched/sched.h:1525 [inline] hardirqs last enabled at (329): [] finish_lock_switch+0xb0/0x1c0 kernel/sched/core.c:5130 hardirqs last disabled at (330): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:511 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: Comprobar la disponibilidad de la cola de trabajo asignada por el controlador wq de idxd antes de usarla. Ejecutar cargas de trabajo IDXD en un contenedor con el directorio /dev montado puede provocar un seguimiento de llamadas o incluso un pánico del kernel cuando finaliza el proceso principal del contenedor. Este problema se produce porque, en ciertas configuraciones, Docker no propaga correctamente la réplica de montaje al punto de montaje original. En este caso, al desconectarse el controlador de usuario, la cola de trabajo se destruye, pero sigue llamando a destroy_workqueue() para intentar completar todo el trabajo pendiente. Es necesario comprobar wq->wq y omitir el vaciado si ya no existe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige una ejecución entre los cambios de nombre y el registro de directorios Tenemos una ejecución entre un cambio de nombre y el registro del inodo del directorio que, si ocurre y nos bloqueamos o falla la energía antes de que se complete el cambio de nombre, la próxima vez que se monte el sistema de archivos, el código de reproducción del registro terminará eliminando el archivo que se estaba cambiando de nombre. Esto se explica mejor siguiendo un análisis paso a paso de un intercalado de pasos que conducen a esta situación. Considere las condiciones iniciales: 1) Estamos en la transacción N; 2) Tenemos los directorios A y B creados en una transacción anterior (< N); 3) Tenemos el inodo X correspondiente a un archivo que tiene 2 enlaces duros, uno en el directorio A y el otro en el directorio B, por lo que los nombraremos como "A/foo_link1" y "B/foo_link2". Ambos enlaces duros persistieron en una transacción anterior (< N); 4) Tenemos el inodo Y, correspondiente a un archivo con un único enlace físico ubicado en el directorio A, al que llamaremos "A/bar". Este archivo también se conservó en una transacción anterior (< N). Los pasos que conducen a la pérdida del archivo son los siguientes, y para todos ellos, estamos en la transacción N: 1) Se elimina el enlace "A/foo_link1", por lo que el campo X last_unlink_trans del inodo se actualiza a N mediante btrfs_unlink() -> btrfs_record_unlink_dir(); 2) La tarea A inicia un cambio de nombre para el inodo Y, con el objetivo de cambiar de "A/bar" a "A/baz", por lo que introducimos btrfs_rename(); 3) La tarea A inserta la nueva clave BTRFS_INODE_REF_KEY para el inodo Y mediante la llamada a btrfs_insert_inode_ref(); 4) Debido a que el cambio de nombre ocurre en el mismo directorio, no establecemos el campo last_unlink_trans del inodo del directorio A en el id de transacción actual, es decir, no llamamos a btrfs_record_unlink_dir(); 5) Luego, la tarea A elimina las entradas del directorio A (elementos BTRFS_DIR_ITEM_KEY y BTRFS_DIR_INDEX_KEY) cuando llama a __btrfs_unlink_inode() (en realidad, el elemento de índice del directorio se agrega como un elemento retrasado, pero el efecto es el mismo); 6) Ahora, antes de que la tarea A agregue la nueva entrada "A/baz" al directorio A llamando a btrfs_add_link(), otra tarea, la tarea B, está registrando el inodo X; 7) La tarea B inicia una sincronización fsync del inodo X y, tras registrarlo, en btrfs_log_inode_parent() llama a btrfs_log_all_parents(), ya que el inodo X tiene un valor de last_unlink_trans de N, establecido en el paso 1. 8) En btrfs_log_all_parents() buscamos todos los directorios padre del inodo X utilizando un root commit, por lo que encontramos los directorios A y B y los registramos. Sin embargo, al registrar directamente A, ya no tenemos un elemento de índice de directorio para el inodo Y, ni para el nombre antiguo "A/bar" ni para el nuevo nombre "A/baz", ya que el cambio de nombre ha eliminado el nombre antiguo, pero aún no ha insertado el nuevo. La tarea A aún no ha llamado a btrfs_add_link() para hacerlo. Tenga en cuenta que registrar el directorio A no recurre a un commit de transacción porque su valor de last_unlink_trans es menor que el ID de la transacción actual (véase el paso 4). 9) La tarea B finaliza el registro de los directorios A y B y regresa a btrfs_sync_file(), donde invoca btrfs_sync_log() para persistir el árbol de registro. 10) La tarea B persistió correctamente el árbol de registro, btrfs_sync_log() se completó correctamente y se produjo un corte de energía. Tenemos un árbol de registro sin ninguna entrada de directorio para el inodo Y, por lo que el código de reproducción del registro elimina la entrada del inodo Y, llamada "A/bar", del árbol de subvolumen, ya que no existe en el árbol de registro y este es autoritario para su índice (registramos un elemento BTRFS_DIR_LOG_INDEX_KEY que cubre el rango de índices de la entrada dentry correspondiente a "A/bar"). ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: maple_tree: corrección del indicador MA_STATE_PREALLOC en mas_preallocate(). Borra temporalmente el indicador de preasignación al solicitar asignaciones explícitamente. Las asignaciones preexistentes ya se contabilizan en la solicitud mediante mas_node_count_gfp(), pero las asignaciones no se realizarán si el indicador MA_STATE_PREALLOC está activado. Este indicador evita la reasignación en modo de asignación masiva y detecta problemas con los cálculos de preasignación. El indicador MA_STATE_PREALLOC debe estar siempre activado en asignaciones cero para que la detección de asignaciones por desbordamiento imprima un WARN_ON() durante el consumo. El efecto visible para el usuario de esta falla es un WARN_ON() seguido de una desreferencia de puntero nulo cuando se ignoran solicitudes posteriores de un mayor número de nodos, como el reintento de fusión de vma en mmap_region() causado por controladores que alteran los indicadores de vma (al menos en la versión 6.6).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: Se corrige una posible desreferencia de puntero nulo. En tegra_crtc_reset(), se asigna nueva memoria con kzalloc(), pero no se realiza ninguna comprobación. Antes de llamar a __drm_atomic_helper_crtc_reset, se debe comprobar el estado para evitar una posible desreferencia de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se ha añadido una comprobación de puntero nulo para get_first_active_display(). La función mod_hdcp_hdcp1_enable_encryption() llama a la función get_first_active_display(), pero no comprueba su valor de retorno. El valor de retorno es un puntero nulo si la lista de visualización está vacía. Esto provocará una desreferencia de puntero nulo en mod_hdcp_hdcp2_enable_encryption(). Se ha añadido una comprobación de puntero nulo para get_first_active_display() y se ha devuelto MOD_HDCP_STATUS_DISPLAY_NOT_FOUND si la función devuelve un valor nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc: Salida explícita del modo seguro CT al desenrollar. Durante la prueba del controlador, podríamos usar brevemente el modo seguro CT, que se basa en un trabajo retrasado, pero normalmente podemos detenerlo una vez que IRQ esté completamente operativo. Sin embargo, si cancelamos la prueba antes de tiempo, durante la desenrollación podríamos intentar destruir la cola de trabajos mientras aún haya un trabajo retrasado pendiente que intenta reiniciarse, lo que activa una advertencia. Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] ------------[ cut here ]------------ [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710 [ ] RIP: 0010:__queue_work+0x287/0x710 [ ] Call Trace: [ ] delayed_work_timer_fn+0x19/0x30 [ ] call_timer_fn+0xa1/0x2a0 Salga del modo seguro de CT al desenrollar para evitar esa advertencia. (seleccionado del commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Proceso diferido de eliminaciones de nodos GGTT al desenrollar el dispositivo Mientras drenamos indirectamente nuestra cola de trabajo dedicada ggtt->wq que usamos para completar la eliminación asincrónica de algunos nodos GGTT, esto sucede como parte del desenrollado de managed-drm (ggtt_fini_early), que podría ser posterior al desenrollado de managed-device, donde ya podríamos desasignar nuestra asignación MMIO/GMS (mmio_fini). Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes) and this was leading to: [ ] BUG: unable to handle page fault for address: ffffc900058162a0 [ ] #PF: supervisor write access in kernel mode [ ] #PF: error_code(0x0002) - not-present page [ ] Oops: Oops: 0002 [#1] SMP NOPTI [ ] Tainted: [W]=WARN [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe] [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe] [ ] Call Trace: [ ] [ ] xe_ggtt_clear+0xb0/0x270 [xe] [ ] ggtt_node_remove+0xbb/0x120 [xe] [ ] ggtt_node_remove_work_func+0x30/0x50 [xe] [ ] process_one_work+0x22b/0x6f0 [ ] worker_thread+0x1e8/0x3d Se agregó una acción de dispositivo administrado que drenará explícitamente la cola de trabajo con todas las eliminaciones de nodos pendientes antes de liberar la asignación de MMIO/GSM. (Seleccionado del commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)