Vulnerabilidades

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: 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: 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: RISC-V: KVM: Desmontaje de bits específicos de RISCV después de kvm_exit. Durante la eliminación de un módulo, kvm_exit invoca una llamada de desactivación específica de la arquitectura, que deshabilita AIA. Sin embargo, al invocar aia_exit antes de kvm_exit, se genera la siguiente advertencia. El módulo del kernel KVM no se puede insertar posteriormente debido a un estado inconsistente de IRQ. [25469.031389] ¡IRQ 31 por CPU sigue habilitado en CPU0! [25469.031732] ADVERTENCIA: CPU: 3 PID: 943 en kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150 [25469.031804] Módulos vinculados: kvm(-) [25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod No contaminado 6.14.0-rc5-06947-g91c763118f47-dirty #2 [25469.031905] Nombre del hardware: riscv-virtio,qemu (DT) [25469.031928] epc : __free_percpu_irq+0xa2/0x150 [25469.031976] ra : __free_percpu_irq+0xa2/0x150 [25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50 [25469.032241] gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8 [25469.032285] t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90 [25469.032329] s1: ff60000098b21080 a0: 037d527a15eb4f00 a1: 037d527a15eb4f00 [25469.032372] a2: 0000000000000023 a3: 0000000000000001 a4 : ffffffff8122dbf8 [25469.032410] a5 : 0000000000000fff a6 : 00000000000000000 a7 : ffffffff8122dc10 [25469.032448] s2 : ff60000080c22eb0 s3: 0000000200000022 s4: 000000000000001f [25469.032488] s5: ff60000080c22e00 s6: ffffffff80c351c0 s7: 0000000000000000 [25469.032582] s8: 0000000000000003 s9: 000055556b7fb490 s10: 00007ffff0e12fa0 [25469.032621] s11: 00007ffff0e13e9a t3: ffffffff81354ac7 t4: ffffffff81354ac7 [25469.032664] t5: ffffffff81354ac8 t6: ffffffff81354ac7 [25469.032698] estado: 0000000200000100 dirección incorrecta: ffffffff8007db1e causa: 0000000000000003 [25469.032738] [] __free_percpu_irq+0xa2/0x150 [25469.032797] [] free_percpu_irq+0x30/0x5e [25469.032856] [] kvm_riscv_aia_exit+0x40/0x42 [kvm] [25469.033947] [] módulo_limpieza+0x10/0x32 [kvm] [25469.035300] [] __riscv_sys_delete_module+0x18e/0x1fc [25469.035374] [] controlador_de_llamadas_al_sistema+0x3a/0x46 [25469.035456] [] do_trap_ecall_u+0x72/0x134 [25469.035536] [] handle_exception+0x148/0x156 Invoca aia_exit y otras funciones de limpieza específicas de la arquitectura después de kvm_exit para que deshabilitar tenga la oportunidad de ser llamado primero antes de salir.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: temporizador: No se utiliza register_mutex con copy_from/to_user(). El infame bloqueo mmap utilizado en copy_from/to_user() puede ser problemático cuando se invoca dentro de otro mutex, ya que podría provocar interbloqueos. En el caso del código del temporizador ALSA, el patrón incorrecto se encuentra en guard(mutex)(&register_mutex) que cubre copy_from/to_user(), que se introdujo por error al convertir a guard() y que ya se había solucionado cuidadosamente en el pasado. Este parche corrige estos problemas simplemente sacando copy_from/to_user() del bloqueo mutex de registro.

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