Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid1,raid10: no ignorar los indicadores de E/S. Si blk-wbt está habilitado por defecto, el rendimiento de escritura en RAID es bastante bajo, ya que todas las E/S son limitadas por wbt de los discos subyacentes, debido a que se ignora el indicador REQ_IDLE. Resulta que este comportamiento existe desde la introducción de blk-wbt. Además de REQ_IDLE, tampoco se deben ignorar otros indicadores; por ejemplo, se puede configurar REQ_META para sistemas de archivos; borrarlo puede causar problemas de inversión de prioridad. REQ_NOWAIT tampoco se debe borrar, ya que la E/S esperará en lugar de fallar directamente en los discos subyacentes. Para solucionar estos problemas, mantenga los indicadores de E/S de la bios maestra. Fises: f51d46d0e7cb ("md: añadir soporte para REQ_NOWAIT")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige un posible bucle muerto en prepare_compress_overwrite() Jan Prusakowski informó un problema de bloqueo del kernel como se muestra a continuación: Al ejecutar xfstests en el kernel linux-next (6.14.0-rc3, 6.12), encontré un problema en la prueba generic/475 donde el proceso fsstress se bloquea en __f2fs_write_data_pages() y la prueba se bloquea. Las opciones que utilicé son: MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc INFO: la tarea kworker/u8:0:11 se bloqueó durante más de 122 segundos. No contaminado 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. tarea:kworker/u8:0 estado:D pila:0 pid:11 tgid:11 ppid:2 indicadores_de_tarea:0x4208160 indicadores:0x00004000 Cola de trabajo: reescritura wb_workfn (flush-253:0) Rastreo de llamadas: __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 La causa raíz es: una vez que generic/475 comienza a cargar la tabla de errores en el dispositivo dm, f2fs_prepare_compress_overwrite() leerá en bucle las páginas comprimidas del clúster debido a un error de E/S, mientras mantiene el bloqueo .writepages, puede bloquear todas las demás tareas de escritura diferida. Solucionemos este problema con los siguientes cambios: - agregue f2fs_handle_page_eio() en prepare_compress_overwrite() para detectar errores de E/S. - detecte cp_error antes en f2fs_read_multi_pages().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Borrar la sugerencia de afinidad antes de llamar a ath12k_pci_free_irq() en la ruta de error Si el controlador usa una IRQ compartida debido a una limitación de la plataforma, la sugerencia de afinidad de IRQ se establece justo después de la asignación de vectores de IRQ en ath12k_pci_msi_alloc(). Esto no causa daño a menos que una de las funciones que solicita la IRQ falle e intente liberarla. Esto puede terminar con una advertencia del núcleo de IRQ que espera que se borre la sugerencia de afinidad antes de liberar la IRQ: kernel/irq/manage.c: /* asegúrese de que affinity_hint se limpie */ if (WARN_ON_ONCE(desc->affinity_hint)) desc->affinity_hint = NULL; Para solucionar este problema, borre la indicación de afinidad de IRQ antes de llamar a ath12k_pci_free_irq() en la ruta de error. La afinidad se borrará más adelante en la ruta de error debido a la organización del código, pero esto no perjudica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: corregir mddev uaf mientras se itera la lista all_mddevs Mientras se itera la lista all_mddevs desde md_notify_reboot() y md_exit(), se usa list_for_each_entry_safe, y esto puede competir con deletint en el siguiente mddev, lo que causa UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // asumir que mddev2 es la siguiente entrada spin_unlock t2: //eliminar mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continuar la desreferencia de mddev2->all_mddevs El antiguo ayudante for_each_mddev() en realidad toma la referencia de mddev2 mientras mantiene el bloqueo, para evitar ser Liberado. Este problema se puede solucionar de la misma manera; sin embargo, el código será complejo. Por lo tanto, cambie a list_for_each_entry; en este caso, mddev_put() puede liberar el mddev1, lo cual tampoco es seguro. Consulte md_seq_show() y también descarte la función auxiliar mddev_put_locked() para solucionar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: ir a la etiqueta derecha 'out_mmap_sem' en ext4_setattr(). De lo contrario, si ext4_inode_attach_jinode() falla, se producirá una tarea bloqueada porque no se llama a filemap_invalidate_unlock() para desbloquear mapping->invalidate_lock. Así: Error de EXT4-fs (dispositivo sda) en ext4_setattr:5557: Memoria insuficiente. INFORMACIÓN: tarea fsstress:374 bloqueada durante más de 122 segundos. No contaminada. 6.14.0-rc1-next-20250206-xfstests-dirty #726 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea: fsstress estado: D pila: 0 pid: 374 tgid: 374 ppid: 373 indicadores de tarea: 0x440140 indicadores: 0x00000000 Rastreo de llamadas: __schedule+0x2c9/0x7f0 schedule+0x27/0xa0 schedule_preempt_disabled+0x15/0x30 rwsem_down_read_slowpath+0x278/0x4c0 down_read+0x59/0xb0 page_cache_ra_unbounded+0x65/0x1b0 filemap_get_pages+0x124/0x3e0 filemap_read+0x114/0x3d0 vfs_read+0x297/0x360 ksys_read+0x6c/0xe0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Enmascarar correctamente el campo bd_cnt en el TX BD El campo bd_cnt en el TX BD especifica el número total de BD para el paquete TX. El campo bd_cnt tiene 5 bits y el número máximo admitido es 32 con el valor 0. CONFIG_MAX_SKB_FRAGS se puede modificar y el número total de fragmentos SKB puede acercarse o superar el máximo admitido por el chip. Agregue una macro para enmascarar correctamente el campo bd_cnt para que el valor 32 se enmascare correctamente y se establezca en 0 en el campo bd_cnd. Sin este parche, el valor bd_cnt fuera de rango corromperá el TX BD y puede causar tiempo de espera de TX. El siguiente parche verificará los valores que excedan 32.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ax25: Eliminar el autobind roto El enlace del socket AX25 mediante la función autobind genera pérdidas de memoria en ax25_connect() y también pérdidas de recuento de referencias en ax25_release(). Se detectó una fuga de memoria con kmemleak: == ... __sys_connect (net/socket.c:2064) __x64_sys_connect (net/socket.c:2067) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) ===================================================================== Cuando se enlaza un socket, los recuentos de referencias se deben incrementar de la forma en que se hace en ax25_bind() y ax25_setsockopt() (SO_BINDTODEVICE). En caso de enlace automático, los recuentos de referencias no se incrementan. Este error provoca el siguiente problema reportado por Syzkaller: == ... ADVERTENCIA: CPU: 0 PID: 5317 en lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 Módulos vinculados: CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 No contaminado 6.14.0-rc4-syzkaller-00278-gece144f151ac #0 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 ... Rastreo de llamadas: __refcount_dec include/linux/refcount.h:336 [en línea] refcount_dec include/linux/refcount.h:351 [en línea] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [en línea] netdev_put include/linux/netdevice.h:4319 [en línea] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [en línea] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [en línea] __se_sys_close fs/open.c:1565 [en línea] __x64_sys_close+0x7f/0x110 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ===================================================================== Considerando los problemas anteriores y los comentarios que se dejaron en el código que dicen: "check Si podemos eliminar esta función, está defectuosa."; "La vinculación automática en este caso puede o no funcionar."; - Es mejor eliminar esta función por completo que corregirla, ya que está defectuosa y provoca diversos errores de memoria. Ahora, llamar a connect() sin vincular primero el socket generará un error (-EINVAL). El software de espacio de usuario que depende de la función de vinculación automática podría fallar. Sin embargo, esta función no parece ser muy utilizada con este controlador específico, ya que no era fiable en ningún momento y, de todos modos, ya está defectuosa. Por ejemplo, los paquetes ax25-tools y ax25-apps para distribuciones populares no utilizan la función de vinculación automática para AF_AX25. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nfnetlink_queue: Inicializar ctx para evitar un error de asignación de memoria. Es posible que ctx en nfqnl_build_packet_message() se utilice antes de su inicialización correcta, la cual solo se inicializa mediante nfqnl_get_sk_secctx(). Este parche corrige este problema inicializando lsmctx a un valor seguro al declararlo. Esto es similar a el commit 35fcac7a7c25 ("auditoría: Inicializar lsmctx para evitar un error de asignación de memoria").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Eliminación del movimiento RTNL para SIOCBRADDIF y SIOCBRDELIF. SIOCBRDELIF se pasa primero a dev_ioctl() y luego a br_ioctl_call(), lo que provoca un movimiento RTNL innecesario y el splat debajo de [0] bajo presión RTNL. Supongamos que el subproceso A intenta desconectar un dispositivo de un puente y el subproceso B intenta eliminar el puente. En dev_ioctl(), el subproceso A aumenta el refcnt del dispositivo puente mediante netdev_hold() y libera RTNL porque el subproceso br_ioctl_call() también vuelve a adquirir RTNL. En la ventana de ejecución, el subproceso B podría adquirir RTNL e intentar eliminar el dispositivo puente. Luego, rtnl_unlock() del subproceso B liberará RTNL y esperará a netdev_put() del subproceso A. Sin embargo, el subproceso A debe mantener RTNL después del desbloqueo en dev_ifsioc(), lo que puede tardar mucho bajo la presión de RTNL, lo que resulta en el splat del subproceso B. Subproceso A (SIOCBRDELIF) Subproceso B (SIOCBRDELBR) ---------------------- ---------------------- sock_ioctl sock_ioctl `- sock_do_ioctl `- br_ioctl_call `- dev_ioctl `- br_ioctl_stub |- rtnl_lock | |- dev_ifsioc ' ' |- dev = __dev_get_by_name(...) |- netdev_hold(dev, ...) . / |- rtnl_unlock ------. | | |- br_ioctl_call `---> |- rtnl_lock Race | | `- br_ioctl_stub |- br_del_bridge Ventana | | | |- dev = __dev_get_by_name(...) | | | Puede tomar mucho tiempo | `- br_dev_delete(dev, ...) | | | bajo presión RTNL | `- unregister_netdevice_queue(dev, ...) | | | | `- rtnl_unlock \ | |- rtnl_lock <-' `- netdev_run_todo | |- ... `- netdev_run_todo | `- rtnl_unlock |- __rtnl_unlock | |- netdev_wait_allrefs_any |- netdev_put(dev, ...) <----------------' Espere la disminución de refcnt y registre splat a continuación Para evitar bloquear SIOCBRDELBR innecesariamente, no llamemos a dev_ioctl() para SIOCBRADDIF y SIOCBRDELIF. En la ruta dev_ioctl(), hacemos lo siguiente: 1. Copiar struct ifreq por get_user_ifreq en sock_do_ioctl() 2. Verificar CAP_NET_ADMIN en dev_ioctl() 3. Llamar a dev_load() en dev_ioctl() 4. Obtener el dev maestro de ifr.ifr_name en dev_ifsioc() 3. se puede hacer por request_module() en br_ioctl_call(), por lo que movemos 1., 2. y 4. a br_ioctl_stub(). Tenga en cuenta que 2. también se verifica más adelante en add_del_if(), pero se realiza mejor antes de RTNL. SIOCBRADDIF y SIOCBRDELIF se han procesado en dev_ioctl() desde la era anterior a Git, y no parece haber una razón específica para procesarlos allí. [0]: unregister_netdevice: esperando a que wpan3 quede libre. Recuento de uso = 2 ref_tracker: wpan3@ffff8880662d8608 tiene 1/1 usuarios en __netdev_tracker_alloc include/linux/netdevice.h:4282 [en línea] netdev_hold include/linux/netdevice.h:4311 [en línea] dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624 dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826 sock_do_ioctl+0x1ca/0x260 net/socket.c:1213 sock_ioctl+0x23a/0x6c0 net/socket.c:1318 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:906 [en línea] __se_sys_ioctl fs/ioctl.c:892 [en línea] __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: se corrige el acceso fuera de rango de la matriz vnic_info. La cola bnxt_queue_{start | stop}() accede a vnic_info tanto como está asignado, lo que indica bp->nr_vnics. Por lo tanto, no debería alcanzar bp->vnic_info[bp->nr_vnics].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar el registro en diario de la actualización de sb en caso de error si el diario se está destruyendo. Actualmente, siempre aplicamos BUG_ON al intentar iniciar una transacción en un diario marcado con JBD2_UNMOUNT, ya que esto nunca debería ocurrir. Sin embargo, mientras ltp ejecutaba pruebas de estrés, se observó que en caso de algunas rutas de gestión de errores, es posible que update_super_work inicie una transacción después de que el diario se destruya, por ejemplo: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Por lo tanto, se introduce un nuevo indicador de montaje para indicar que el diario se está destruyendo y solo se realiza una actualización registrada (y diferida) de sb si este indicador no está configurado. De lo contrario, simplemente se recurre a una confirmación no registrada. Además, en la ruta de destrucción del diario, tenemos la siguiente secuencia: 1. Establecer el indicador de montaje que indica que el diario se está destruyendo 2. forzar una confirmación y esperarla 3. vaciar las actualizaciones pendientes del sb Esta secuencia es importante ya que garantiza que, después de este punto, no haya ninguna actualización del sb que pueda registrarse, por lo que es seguro actualizar el sb fuera del diario. (Para evitar la ejecución discutida en 2d01ddc86606) Además, no necesitamos una comprobación similar en ext4_grp_locked_error ya que solo se llama desde mballoc y AFAICT siempre sería válido programar el trabajo aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no modificar la matriz de fragmentos del sistema en btrfs_validate_super(). El commit 2a9bb78cfd36 ("btrfs: validar la matriz de fragmentos del sistema en btrfs_validate_super()") introduce una llamada a validate_sys_chunk_array() en btrfs_validate_super(), que modifica el valor de ret establecido previamente. Esto invalida las comprobaciones de validez realizadas previamente, lo que permite que btrfs intente montar sistemas de archivos no válidos.