Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: Reemplace rq_lock() por raw_spin_rq_lock() en scx_ops_bypass() scx_ops_bypass() itera todas las CPU para volver a poner en cola todas las tareas de scx. Para cada CPU, adquiere un bloqueo mediante rq_lock() independientemente de si una CPU está fuera de línea o si la CPU está ejecutando actualmente una tarea en una clase de programador superior (por ejemplo, fecha límite). Se supone que rq_lock() se debe utilizar para CPU en línea, y el uso de rq_lock() puede activar una advertencia innecesaria en rq_pin_lock(). Por lo tanto, reemplace rq_lock() por raw_spin_rq_lock() en scx_ops_bypass(). Sin este cambio, observamos la siguiente advertencia: ===== START ===== [ 6.615205] rq->balance_callback && rq->balance_callback != &balance_push_callback [ 6.615208] ADVERTENCIA: CPU: 2 PID: 0 en kernel/sched/sched.h:1730 __schedule+0x1130/0x1c90 ===== END ==========

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: evitar la desreferencia de puntero NULL si no hay un árbol de extensión válido [ERROR] Syzbot informó de un fallo con el siguiente seguimiento de llamada: Información de BTRFS (bucle de dispositivo 0): scrub: iniciado en devid 1 ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000208 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: cargado Tainted: G O 6.13.0-rc4-custom+ #206 Tainted: [O]=OOT_MODULE Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS desconocido 02/02/2022 RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs] Seguimiento de llamadas: Scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs] Scrub_simple_mirror+0x175/0x260 [btrfs] Scrub_stripe+0x5d4/0x6c0 [btrfs] Scrub_chunk+0xbb/0x170 [btrfs] Scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs] btrfs_scrub_dev+0x240/0x600 [btrfs] btrfs_ioctl+0x1dc8/0x2fa0 [btrfs] ? do_sys_openat2+0xa5/0xf0 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSA] El reproductor está usando una imagen dañada donde la raíz del árbol de extensión está dañada, lo que obliga a usar la opción de montaje "rescue=all,ro" para montar la imagen. Luego, activó una limpieza, pero como la limpieza depende del árbol de extensión para encontrar dónde están las extensiones de datos/metadatos, scrub_find_fill_first_stripe() depende de una raíz de extensión no vacía. Pero desafortunadamente scrub_find_fill_first_stripe() no espera realmente un puntero NULL para la raíz de la extensión, usa extended_root para obtener fs_info y activa una desreferencia de puntero NULL. [SOLUCIÓN] Agregue una verificación adicional para una raíz de extensión válida al comienzo de scrub_find_fill_first_stripe(). La nueva ruta de error es introducida por 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots"), pero eso es bastante antiguo, y el commit posterior b979547513ff ("btrfs: scrub: introduce helper to find and fill sector info for a scrub_stripe") cambió la forma en que realizamos el scrub. Entonces, para los kernels anteriores a 6.6, la solución necesitará una adaptación manual.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdev: evitar el acceso a instancias NAPI desde otro espacio de nombres Los identificadores NAPI no estaban completamente expuestos al espacio de usuario antes de la API netlink, por lo que nunca se asignaron espacios de nombres. La API netlink debe garantizar que, como mínimo, la instancia NAPI pertenezca a la misma red que el propietario del calcetín genl. napi_by_id() ahora puede volverse estático, pero debe moverse debido a dev_get_by_napi_id().

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().