Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: actualizar la lista de canales en el notificador de registros en lugar del trabajador de registros. Actualmente, cuando ath11k obtiene una nueva lista de canales, esta se procesa según los siguientes pasos: 1. Actualizar la nueva lista de canales a cfg80211 y poner en cola reg_work. 2. cfg80211 gestiona la nueva lista de canales durante reg_work. 3. Actualizar la lista de canales gestionada de cfg80211 al firmware mediante ath11k_reg_update_chan_list(). Sin embargo, ath11k ejecutará inmediatamente el paso 3 después de poner en cola reg_work. Como el paso 2 es asincrónico, es posible que cfg80211 no haya terminado de manejar la nueva lista de canales, lo que puede generar un error de escritura fuera de los límites: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Se debe asegurar que el paso 2 se haya realizado completamente antes de ejecutar el paso 3. Por lo tanto, Wen planteó patch[1]. Cuando se activa el indicador NL80211_REGDOM_SET_BY_DRIVER, cfg80211 notificará a ath11k una vez finalizado el paso 2. Por lo tanto, al activar el indicador NL80211_REGDOM_SET_BY_DRIVER, cfg80211 notificará a ath11k una vez finalizado el paso 2. En este momento, no se producirá ningún error de KASAN durante la ejecución del paso 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Probado en: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: cuota: corrección para evitar advertencias en dquot_writeback_dquots() F2FS-fs (dm-59): checkpoint=enable tiene algunos datos no escritos. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 6 PID: 8013 en fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308 pc : dquot_writeback_dquots+0x2fc/0x308 lr : f2fs_quota_sync+0xcc/0x1c4 Rastreo de llamadas: dquot_writeback_dquots+0x2fc/0x308 f2fs_quota_sync+0xcc/0x1c4 f2fs_write_checkpoint+0x3d4/0x9b0 f2fs_issue_checkpoint+0x1bc/0x2c0 f2fs_sync_fs+0x54/0x150 f2fs_do_sync_file+0x2f8/0x814 __f2fs_ioctl+0x1960/0x3244 f2fs_ioctl+0x54/0xe0 __arm64_sys_ioctl+0xa8/0xe4 evolve_syscall+0x58/0x114 el punto de control y f2fs_remount pueden competir como se muestra a continuación, lo que activa una advertencia en dquot_writeback_dquots(). remot de escritura atómica - do_remount - down_write(&sb->s_umount); - f2fs_remount - ioctl - f2fs_do_sync_file - f2fs_sync_fs - f2fs_write_checkpoint - block_operations - locking = down_read_trylock(&sbi->sb->s_umount) : no se pudo bloquear debido a que el bloqueo de escritura fue mantenido por el remot - up_write(&sb->s_umount); - f2fs_quota_sync - dquot_writeback_dquots - WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)) : activa una advertencia porque el bloqueo s_umount se desbloqueó al volver a montar Si el punto de control proviene de mount/umount/remount/freeze/quotactl, el llamador del punto de control ya ha mantenido el bloqueo s_umount, llamar a dquot_writeback_dquots() en el contexto debería ser seguro. Así que grabemos la tarea en sbi->umount_lock_holder, para que el punto de control pueda saber si el bloqueo se ha mantenido en el contexto o no al verificar la corriente con él. Además, para no tergiversar la llamada del punto de control, no deberíamos permitir que se active el punto de control asíncrono para esos llamadores: mount/umount/remount/freeze/quotactl.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dlm: impide NPD al escribir un valor positivo en event_done. do_uevent devuelve el valor escrito en event_done. En caso de ser un valor positivo, new_lockspace desharía todo el trabajo y no se establecería el espacio de bloqueo. Sin embargo, __dlm_new_lockspace trataría ese valor positivo como un éxito debido a el commit 8511a2728ab8 ("dlm: corrige el recuento de uso con múltiples uniones"). Posteriormente, device_create_lockspace pasaría ese espacio de bloqueo nulo a dlm_find_lockspace_local, lo que provocaría una desreferencia de puntero nulo. Tratar estos valores positivos como éxitos evita el problema. Dado que esto ha estado roto durante tanto tiempo, es improbable que esto altere las expectativas del espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el pánico cuando falla la fallocation para el archivo PIN syzbot informa un error de f2fs como el siguiente: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 No contaminado 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [en línea] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Rastreo de llamadas: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [en línea] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 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 La asignación simultánea de archivos PIN puede agotar la sección libre, lo que genera un pánico en get_new_segment(). Expandamos la cobertura del bloqueo de PIN_SEM para incluir f2fs_gc() y así asegurarnos de recuperar suficiente espacio libre para la siguiente asignación. Además, implementemos los siguientes cambios para mejorar la gestión de rutas de error: - Llamar a f2fs_bug_on() solo en rutas de asignación que no sean archivos PIN en get_new_segment(). - Llamar a reset_curseg_fields() para restablecer todos los campos de curseg en new_curseg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: térmica: int340x: Añadir comprobación de valores nulos para adev. No todos los dispositivos tienen un nodo auxiliar ACPI, por lo que adev podría ser nulo. Esto es similar a el commit cd2fd6eab480 ("plataforma/x86: int3472: Comprobar si adev == NULL"). Añadir una comprobación para comprobar si adev no está configurado y devolver -ENODEV en ese caso para evitar una posible desreferencia de puntero nulo en int3402_thermal_probe(). Cabe destacar que, en el mismo directorio, int3400_thermal_probe() cuenta con dicha comprobación. [rjw: Edición del tema, correcciones añadidas]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: Borrar la indicación de afinidad antes de llamar a ath11k_pcic_free_irq() en la ruta de error. Si el controlador utiliza una IRQ compartida debido a una limitación de la plataforma, la indicación de afinidad de IRQ se establece justo después de la asignación de vectores IRQ en ath11k_pci_alloc_msi(). Esto no causa ningún problema a menos que una de las funciones que solicita la IRQ falle e intente liberarla. Esto da como resultado la siguiente advertencia: ADVERTENCIA: CPU: 7 PID: 349 en kernel/irq/manage.c:1929 free_irq+0x278/0x29c Rastreo de llamadas: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc La advertencia se debe a que no se borra la sugerencia de afinidad antes de liberar las IRQ. Por lo tanto, para solucionar este problema, borre la sugerencia de afinidad de IRQ antes de llamar a ath11k_pcic_free_irq() en la ruta de error. La afinidad se borrará una vez más más adelante en la ruta de error debido a la organización del código, pero eso no hace daño. Probado en: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de lectura fuera de límite en ext4_xattr_inode_dec_ref_all() Hay el siguiente problema: ERROR: KASAN: use-after-free en ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Lectura de tamaño 4 en la dirección ffff88807b003000 por la tarea syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Rastreo de llamadas: __dump_stack lib/dump_stack.c:82 [en línea] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [en línea] iput fs/inode.c:1772 [en línea] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [en línea] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [en línea] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [en línea] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Estado de la memoria alrededor de la dirección con errores: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff El problema anterior ocurre porque ext4_xattr_delete_inode() no verifica que xattr sea válido si xattr está en el inodo. Para resolver el problema anterior, llame a xattr_check_inode() para verificar si xattr es válido en el inodo. De hecho, podemos verificar directamente en ext4_iget_extra_inode(), de modo que no haya ninguna verificación divergente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Validar los parámetros de los cuantos de cola para impedir el acceso OOB. Añadir prevención de encapsulamiento de cola en la configuración de cuantos. Asegurar que end_qid no se desborde validando start_qid y num_queues.

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: 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: 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: 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")