Vulnerabilidades

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

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: 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: btrfs: corrección de la ejecución de recuento de referencias de grupos de bloques en btrfs_create_pending_block_groups(). La creación de grupos de bloques se realiza en dos fases, lo que resulta en una propiedad poco intuitiva: un grupo de bloques se puede asignar/desasignar después de que btrfs_make_block_group() lo añada a space_info con btrfs_add_bg_to_space_info(), pero antes de que la creación se complete por completo en btrfs_create_pending_block_groups(). Como resultado, es posible que un grupo de bloques quede sin usar y que se invoque 'btrfs_mark_bg_unused' simultáneamente con 'btrfs_create_pending_block_groups'. Esto causa varios problemas, que se solucionaron con la bandera de grupo de bloques 'BLOCK_GROUP_FLAG_NEW'. Sin embargo, esta corrección no está del todo completa. Dado que no utiliza el bloqueo de bloques no utilizados (unused_bg_lock), es posible que se produzca la siguiente ejecución: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail. Y llegamos al mismo estado de recuento de referencias erróneo y new_bgs no válido para la limpieza de transacciones, que BLOCK_GROUP_FLAG_NEW pretendía evitar. El aspecto de recuento de referencias erróneo generará una advertencia como: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] ADVERTENCIA: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]--- Aunque también los hemos visto en la función de trabajo de descarte asíncrono. Es más probable que ocurra después de finalizar una reubicación que cancela el descarte, desmantela el grupo de bloques, etc. Solucione esto completamente desmantelando el bloqueo de ---truncated---

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.

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].