Vulnerabilidades

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/md-bitmap: corrige bitmap_limit incorrecto para clustermd al escribir sb En clustermd, se usan mapas de bits de intención de escritura separados para cada nodo del clúster: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | Entonces, en el nodo 1, pg_index en __write_sb_page() podría ser igual a bitmap->storage.file_pages. Entonces, bitmap_limit se calculará como 0. md_super_write() se llamará con un tamaño de 0. Esto significa que la primera área de 4k del nodo 1 nunca se actualizará mediante filemap_write_page(). Este error provoca el bloqueo de mdadm/clustermd_tests/01r1_Grow_resize. En este caso, utilice (pg_index % bitmap->storage.file_pages) para que el cálculo de bitmap_limit sea correcto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el acceso a curseg no inicializado syzbot informa un error de f2fs como el siguiente: F2FS-fs (loop3): sistema de archivos detenido por el motivo: 7 kworker/u8:7: intento de acceso más allá del final del dispositivo ERROR: no se puede controlar el error de página para la dirección: ffffed1604ea3dfa RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline] RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline] RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline] RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649 f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline] f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791 write_inode fs/fs-writeback.c:1525 [inline] __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745 writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976 wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156 wb_do_writeback fs/fs-writeback.c:2303 [inline] wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Commit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") permite que no se active ninguna falla de segmento libre en el asignador, luego se actualizará curseg->segno to NULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() No se pudo verificar la bandera y el acceso no es válido curseg->segno directly En la siguiente ruta de llamada, lo que genera pánico: - f2fs_write_inode - f2fs_is_checkpoint_ready - has_enough_free_secs - has_not_enough_free_secs - __get_secs_required - has_curseg_enough_space - get_ckpt_valid_blocks : access invalid curseg->segno Para evitar este problema, vamos a: - check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in f2fs_write_inode(). - in has_curseg_enough_space(), save curseg->segno en una variable temporal y verificar su validación antes de usar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corrección. Se permite añadir un folio a la biografía a partir de 4 GB en algunos ARCH, como aarch64. Se admite una página enorme de 16 GB. En ese caso, el desplazamiento del folio no se puede guardar en una entero sin signo, lo que provoca una advertencia en bio_add_folio_nofail() y un fallo de E/S. Se soluciona ajustando la página y recortando el desplazamiento para que `->bi_offset` no se desborde y el folio se pueda añadir a la biografía correctamente.

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: wifi: cfg80211: falla la inicialización de wiphy_work antes de asignar rfkill. syzbort reportó un bloqueo de wiphy_work sin inicializar en cfg80211_dev_free. [1] Tras el fallo de la asignación de rfkill, se ejecutará el proceso de liberación de wiphy, lo que provocará que cfg80211_dev_free acceda a los datos relacionados con wiphy_work sin inicializar. Para evitar este problema, cambie la inicialización de wiphy_work a una anterior a la inicialización de rfkill. [1] INFORMACIÓN: Se intenta registrar una clave no estática. El código funciona correctamente, pero necesita la anotación lockdep. ¿O quizás no inicializó este objeto antes de usarlo? Desactivando el validador de corrección de bloqueo. CPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 No contaminado 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 assign_lock_key kernel/locking/lockdep.c:983 [inline] register_lock_class+0xc39/0x1240 kernel/locking/lockdep.c:1297 __lock_acquire+0x135/0x3c40 kernel/locking/lockdep.c:5103 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162 cfg80211_dev_free+0x30/0x3d0 net/wireless/core.c:1196 device_release+0xa1/0x240 drivers/base/core.c:2568 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1e4/0x5a0 lib/kobject.c:737 put_device+0x1f/0x30 drivers/base/core.c:3774 wiphy_free net/wireless/core.c:1224 [inline] wiphy_new_nm+0x1c1f/0x2160 net/wireless/core.c:562 ieee80211_alloc_hw_nm+0x1b7a/0x2260 net/mac80211/main.c:835 mac80211_hwsim_new_radio+0x1d6/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5185 hwsim_new_radio_nl+0xb42/0x12b0 drivers/net/wireless/virtual/mac80211_hwsim.c:6242 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2533 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1882 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg net/socket.c:733 [inline] ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2573 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2627 __sys_sendmsg+0x16e/0x220 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 Close: https://syzkaller.appspot.com/bug?extid=aaf0488c83d1d5f4f029

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