Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: virtuser: corregir limpiezas de tablas de búsqueda faltantes Cuando se crea un dispositivo virtuser a través de configfs y la sonda falla debido a una tabla de búsqueda incorrecta, la tabla no se elimina. Esto evita que los intentos de sonda posteriores tengan éxito, incluso si se corrige el problema, a menos que se libere el dispositivo. Además, también se necesita limpieza en el caso menos probable de que falle platform_device_register_full(). Además, se detectó una pérdida de memoria constante en lookup_table->dev_id usando kmemleak alternando el estado activo entre 0 y 1 con una tabla de búsqueda correcta. Introduzca gpio_virtuser_remove_lookup_table() como contraparte del gpio_virtuser_make_lookup_table() existente y llámelo desde todos los puntos necesarios para garantizar una limpieza adecuada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: dwmac-tegra: Leer el ID de flujo de iommu del árbol de dispositivos Los controladores Tegra MGBE de Nvidia requieren que el "ID de flujo" (SID) de IOMMU se escriba en el registro MGBE_WRAP_AXI_ASID0_CTRL. El controlador actual está codificado de forma rígida para utilizar el SID de MGBE0 para todos los controladores. Esto provoca tiempos de espera de softirq y pánicos del kernel cuando se utilizan controladores distintos de MGBE0. Ejemplo de errores dmesg cuando un cable Ethernet está conectado a MGBE1: [ 116.133290] tegra-mgbe 6910000.ethernet eth1: El enlace está activo - 1 Gbps/completo - control de flujo rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: la cola de transmisión 0 agotó el tiempo de espera de 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reiniciar el adaptador. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Registrar MEM_TYPE_PAGE_POOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: Controlador PHY [stmmac-1:00] [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Habilitación de funciones de seguridad [ 121.907578] tegra-mgbe 6910000.ethernet eth1: Marca de tiempo avanzada IEEE 1588-2008 compatible [ 121.908399] tegra-mgbe 6910000.ethernet eth1: Reloj PTP registrado [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configurando para modo de enlace phy/10gbase-r [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Enlace activo - 1 Gbps/completo - control de flujo rx/tx [ 181.921198] rcu: INFORMACIÓN: rcu_preempt detectó bloqueos en CPU/tareas: [ 181.921404] rcu: 7-....: (1 GP detrás) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detectado por 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Enviando NMI desde la CPU 4 a las CPU 7: [ 181.921886] Seguimiento de NMI para la CPU 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: cargado No contaminado 6.13.0-rc3+ #6 [ 181.922390] Nombre del hardware: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 28/10/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handle_softirqs+0x98/0x368 [ 181.922978] lr : __do_softirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8: ffff8000827b3160 x7: f9157b241586f343 x6: eeb6502a01c81c74 [181.953068] x5: a4acfcdd2e8096bb x4: ffffce78ea277340 x3: 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Rastreo de llamadas: [ 181.970043] handle_softirqs+0x98/0x368 (P) [ 181.974240] __do_softirq+0x18/0x20 [ 181.977743] ____do_softirq+0x14/0x28 [ 181.981415] call_on_irq_stack+0x24/0x30 [ 181.985180] do_softirq_own_stack+0x20/0x30 [ 181.989379] __irq_exit_rcu+0x114/0x140 [ 181.993142] irq_exit_rcu+0x14/0x28 [ 181.996816] el1_interrupt+0x44/0xb8 [ 182.000316] el1h_64_irq_handler+0x14/0x20 [ 182.004343] el1h_64_irq+0x80/0x88 [ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P) [ 182.012305] cpuidle_enter+0x3c/0x58 [ 182.015980] cpuidle_idle_call+0x128/0x1c0 [ 182.020005] do_idle+0xe0/0xf0 [ 182.023155] cpu_startup_entry+0x3c/0x48 [ 182.026917] secondary_start_kernel+0xdc/0x120 [ 182.031379] __secondary_switched+0x74/0x78 [ 212.971162] rcu:---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-blk: no mantener la cola congelada durante la suspensión del sistema. Commit 4ce6e2db00de ("virtio-blk: Asegúrese de que no haya solicitudes en virtqueues antes de eliminar vqs") reemplaza la inactividad de la cola con el congelamiento de la cola en las devoluciones de llamadas de PM de virtio-blk. Y la motivación es drenar las E/S en vuelo antes de suspender. El congelamiento de la cola de la capa de bloque parece muy útil, pero también es fácil causar un bloqueo, como, por ejemplo, cualquier intento de llamar a bio_queue_enter() puede encontrarse con un bloqueo si la cola está congelada en el contexto actual. Hay todo tipo de ->suspend() llamados en el contexto de suspensión, por lo que mantener la cola congelada en todo el contexto de suspensión no es una buena idea. Y Marek informó una advertencia de lockdep[1] causada por la cola congelada de virtio-blk en virtblk_freeze(). [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/ Dado que la motivación es drenar las E/S en vuelo, se puede hacer llamando a congelar y descongelar, mientras tanto restaurar el comportamiento anterior manteniendo la cola inactiva durante la suspensión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige la ruta inesperadamente cambiada en ksmbd_vfs_kern_path_locked Cuando `ksmbd_vfs_kern_path_locked` encuentra un error y no es la última entrada, saldrá sin restaurar el búfer de ruta cambiada. Pero más adelante, este búfer se puede usar como nombre de archivo para la creación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se solucionó que la variable no se completara cuando la función retorna Cuando cmd_alloc_index(), falla cmd_work_handler() debe completar ent->slotted antes de regresar antes. De lo contrario, la tarea que emitió el comando puede bloquearse: mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): no se pudo asignar la entrada del comando INFO: la tarea kworker/13:2:4055883 se bloqueó durante más de 120 segundos. No está contaminada 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5e_tx_dim_work [mlx5_core] Call trace: __switch_to+0xe8/0x150 __schedule+0x2a8/0x9b8 schedule+0x2c/0x88 schedule_timeout+0x204/0x478 wait_for_common+0x154/0x250 wait_for_completion+0x28/0x38 cmd_exec+0x7a0/0xa00 [mlx5_core] mlx5_cmd_exec+0x54/0x80 [mlx5_core] mlx5_core_modify_cq+0x6c/0x80 [mlx5_core] mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core] mlx5e_tx_dim_work+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0x18

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: mm: Corrige el problema de salida de límites de la dirección vmemmap En el modelo vmemmap disperso, la dirección virtual de vmemmap se calcula como: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). Y la va de la página de estructura se puede calcular con un desplazamiento: (vmemmap + (pfn)). Sin embargo, al inicializar las páginas de estructura, el kernel en realidad comienza desde la primera página de la misma sección a la que pertenece phys_ram_base. Si la dirección física de la primera página no es (phys_ram_base >> PAGE_SHIFT), obtenemos una va por debajo de VMEMMAP_START al calcular la va para su página de estructura. Por ejemplo, si phys_ram_base comienza desde 0x82000000 con pfn 0x82000, la primera página en la misma sección es en realidad pfn 0x80000. Durante init_unavailable_range(), inicializaremos struct page para pfn 0x80000 con dirección virtual ((struct page *)VMEMMAP_START - 0x2000), que está debajo de VMEMMAP_START y PCI_IO_END. Esta confirmación corrige este error al introducir una nueva variable 'vmemmap_start_pfn' que está alineada con el tamaño de la sección de memoria y la usa para calcular la dirección vmemmap en lugar de phys_ram_base.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Arreglar la (no) cancelación de copia cuando el caché está deshabilitado temporalmente Cuando el almacenamiento en caché de una cookie está deshabilitado temporalmente (por ejemplo, debido a una escritura DIO en ese archivo), la copia futura al caché para ese archivo se deshabilita hasta que todos los fds abiertos en ese archivo se cierren. Sin embargo, si netfslib está usando el método PG_private_2 obsoleto (como el que usa actualmente ceph) y decide que quiere copiar al caché, netfs_advance_write() simplemente abandonará en la primera verificación al ver que el flujo de caché no está disponible e indicará que se ocupó de todo el contenido. Esto significa que no tenemos subsolicitudes para proporcionar notificaciones para controlar la máquina de estado o incluso para fijar la solicitud y la solicitud simplemente se descarta, dejando los folios con PG_private_2 establecido. Arregle esto saltando directamente para cancelar la solicitud si el caché no está disponible. De esa manera, no eliminamos mark3 de la lista folio_queue y netfs_pgpriv2_cancel() limpiará los folios. Esto se descubrió al ejecutar el xfstest genérico/013 contra ceph con un caché activo y la opción "-o fsc" pasada a ceph. Eso generalmente se bloqueaba

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Fix ceph copy to cache on write-begin Al final de netfs_unlock_read_folio() en el que los folios se marcan adecuadamente para copiarlos al caché (ya sea marcándolos como sucios y teniendo sus datos privados configurados o teniendo PG_private_2 configurado) y luego se desbloquean, la estructura folio_queue tiene la entrada que apunta al folio borrada. Esto presenta un problema para netfs_pgpriv2_write_to_the_cache(), que se usa para escribir folios marcados con PG_private_2 en el caché, ya que espera poder rastrear la lista folio_queue a partir de entonces para encontrar los folios relevantes, lo que lleva a un bloqueo. Solucione esto al no borrar la entrada folio_queue si vamos a hacer la copia al caché obsoleta. La limpieza se realizará en su lugar a medida que los folios se escriben en el caché. Esto se puede reproducir iniciando cachefiles, montando un sistema de archivos ceph con "-o fsc" y escribiendo en él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: se corrige que el nuevo búfer no se pusiera a cero antes de escribir. Antes de escribir, si un buffer_head está marcado como nuevo, sus datos deben ponerse a cero; de lo contrario, se escribirán datos no inicializados en la caché de páginas. Por lo tanto, esta confirmación utiliza folio_zero_new_buffers() para poner a cero los nuevos búferes antes de ->write_end().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ti-ads1298: Agregar comprobación NULL en ads1298_init devm_kasprintf() puede devolver un puntero NULL en caso de error. Falta una comprobación del valor de retorno de dicha llamada en ads1298_init(). Añádala.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: se corrige el bucle infinito en exfat_readdir() Si el sistema de archivos está dañado de modo que un clúster está vinculado a sí mismo en la cadena de clústeres y hay una entrada de directorio sin usar en el clúster, 'dentry' no se incrementará, lo que provocará que la condición 'dentry < max_dentries' no pueda evitar un bucle infinito. Este bucle infinito hace que s_lock no se libere y otras tareas se cuelguen, como exfat_sync_fs(). Esta confirmación deja de recorrer la cadena de clústeres cuando hay una entrada de directorio sin usar en el clúster para evitar este bucle infinito.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Se ha corregido la suspensión en un contexto no válido en die(). die() se puede llamar en el controlador de excepciones y, por lo tanto, no puede suspenderse. Sin embargo, die() utiliza spinlock_t, que puede suspenderse con PREEMPT_RT habilitado. Esto provoca la siguiente advertencia: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex preempt_count: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dump_backtrace+0x1c/0x24 show_stack+0x2c/0x38 dump_stack_lvl+0x5a/0x72 dump_stack+0x14/0x1c __might_resched+0x130/0x13a rt_spin_lock+0x2a/0x5c die+0x24/0x112 do_trap_insn_illegal+0xa0/0xea _new_vmalloc_restore_context_a0+0xcc/0xd8 Oops - illegal instruction [#1] Switch to use raw_spinlock_t, que no duerme incluso con PREEMPT_RT habilitado.