Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Evitar fugas de memoria al habilitar las estadísticas. El controlador utiliza anillos de destino del monitor para el modo de estadísticas extendidas y el modo de monitor independiente. En el modo de estadísticas extendidas, los TLV se analizan desde el búfer recibido del anillo de destino del monitor y se asignan a la estructura ppdu_info para actualizar las estadísticas por paquete. En el modo de monitor independiente, junto con las estadísticas por paquete, se capturan los datos del paquete (carga útil) y el controlador actualiza por MSDU a mac80211. Cuando la interfaz AP está habilitada, solo se activa el modo de estadísticas extendidas. Como parte de la habilitación de los anillos de monitor para recopilar estadísticas, el controlador se suscribe al TLV HAL_RX_MPDU_START en la configuración del filtro. Este TLV se recibe del anillo de destino del monitor y se produce kzalloc para el objeto mon_mpdu, que no se libera, lo que provoca una fuga de memoria. El kzalloc para el objeto mon_mpdu solo es necesario mientras se habilita la interfaz de monitor independiente. Esto causa una fuga de memoria al habilitar el modo de estadísticas extendidas en el controlador. Solucione esta fuga de memoria eliminando el kzalloc del objeto mon_mpdu en la gestión de la TLV HAL_RX_MPDU_START. Además, elimine la gestión del modo de monitor independiente en las TLV HAL_MON_BUF_ADDR y HAL_RX_MSDU_END. Estas etiquetas TLV se gestionarán correctamente al habilitar el modo de monitor independiente en el futuro. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: se corrige la pérdida de memoria en ath12k_pci_remove() Kmemleak informó este error: objeto sin referencia 0xffff1c165cec3060 (tamaño 32): comm "insmod", pid 560, jiffies 4296964570 (edad 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 La memoria del firmware se asignó en ath12k_pci_probe(), pero no se liberó en ath12k_pci_remove() si el bit ATH12K_FLAG_QMI_FAIL está activado. Por lo tanto, se llama ath12k_fw_unmap() para liberar la memoria. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: hibernate: Evitar interbloqueo en hibernate_compressor_param_set(). syzbot reportó un interbloqueo en lock_system_sleep() (ver más abajo). La operación de escritura en "/sys/module/hibernate/parameters/compressor" entra en conflicto con el registro del dispositivo ieee80211, lo que resulta en un interbloqueo al intentar adquirir system_transition_mutex bajo param_lock. Para evitar este interbloqueo, modifique hibernate_compressor_param_set() para usar mutex_trylock() al intentar adquirir system_transition_mutex y devolver -EBUSY si falla. No es necesario guardar ni ajustar los indicadores de tarea antes de llamar a mutex_trylock(&system_transition_mutex), ya que el llamador no esperará este mutex y, si se ejecuta simultáneamente con la suspensión del sistema en curso, se congelará correctamente al regresar al espacio de usuario. Informe de syzbot: syz-executor895/5833 está intentando adquirir el bloqueo: ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, en: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56 pero la tarea ya tiene el bloqueo: ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, en: kernel_param_lock kernel/params.c:607 [en línea] ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, en: param_attr_store+0xe6/0x300 kernel/params.c:586 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (param_lock){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [en línea] rate_control_alloc net/mac80211/rate.c:266 [en línea] ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558 init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910 hacer_una_initcall+0x128/0x700 init/main.c:1257 hacer_nivel_initcall init/main.c:1319 [en línea] hacer_initcalls init/main.c:1335 [en línea] hacer_configuración_básica init/main.c:1354 [en línea] kernel_init_freeable+0x5c7/0x900 init/main.c:1568 kernel_init+0x1c/0x2b0 init/main.c:1457 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #2 (rtnl_mutex){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 wg_pm_notification drivers/net/wireguard/device.c:80 [en línea] wg_pm_notification+0x49/0x180 controladores/net/wireguard/device.c:64 cadena_de_llamadas_del_notificador+0xb7/0x410 kernel/notifier.c:85 cadena_de_llamadas_del_notificador_robust kernel/notifier.c:120 [en línea] cadena_de_llamadas_del_notificador_robust kernel/notifier.c:345 [en línea] cadena_de_llamadas_del_notificador_robust+0xc9/0x170 kernel/notifier.c:333 cadena_de_llamadas_del_notificador_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 controladores/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [en línea] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [en línea] __do_sys_openat fs/open.c:1459 [en línea] __se_sys_openat fs/open.c:1454 [en línea] __x64_sys_openat+0x175/0x210 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 ((pm_chain_head).rwsem){++++}-{4:4}: down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 blocking_notifier_call_chain_robust kernel ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/dwc_pcie: se corrigen dispositivos pci_dev duplicados. Durante platform_device_register, el uso incorrecto de struct device pci_dev como platform_data provocaba una copia kmemdup de pci_dev. Peor aún, acceder al dispositivo duplicado provoca la corrupción de la lista, ya que su contenido mutex (p. ej., list, magic) permanece igual que el original.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Se soluciona el bloqueo al liberar el evento sigtrap Perf puede bloquearse al liberar un evento sigtrap si no se ha logrado enviar una señal diferida relacionada antes de que se cerrara el archivo: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Una vez que task_work_run() se está ejecutando, la lista de devoluciones de llamadas pendientes se elimina de task_struct y desde este punto, task_work_cancel() no puede eliminar ningún elemento de trabajo pendiente y aún no iniciado, de ahí el error de task_work_cancel() y el bloqueo de rcuwait_wait_event(). El trabajo de la tarea se puede cambiar para eliminar un trabajo a la vez, de modo que un trabajo que se ejecuta en la tarea actual siempre puede cancelar uno pendiente, sin embargo, el diseño de espera/activación aún está sujeto a dependencias invertidas cuando se involucran objetivos remotos, como lo ilustra Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Por lo tanto, la única opción que queda es adquirir el recuento de referencias de evento al poner en cola el trabajo de la tarea de rendimiento y liberarlo del trabajo de la tarea. Tal como se hizo antes de 3a5465418f5f ("perf: Corregir fuga de eventos al ejecutar y liberar archivos"), pero sin las fugas corregidas. Se requieren algunos ajustes para que funcione: * Un evento secundario podría desreferenciar a su padre al liberarse. Se debe tener cuidado de liberar al padre al final. * Algunos sitios, al asumir que el evento no tiene ninguna referencia retenida y, por lo tanto, puede liberarse de inmediato, deben colocar la referencia y dejar que el recuento de referencias continúe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/cpu: Evitar la ejecución al final de una tabla de erratas de AMD. El terminador de matriz NULL al final de erratum_1386_microcode se eliminó durante la migración de x86_cpu_desc a x86_cpu_id. Esto provoca que los lectores se ejecuten al final de la matriz. Reemplace el NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir UAF en descifrado con multicanal Después de la confirmación f7025d861694 ("smb: cliente: asignar criptografía solo para el servidor principal") y la confirmación b0abcd65ec54 ("smb: cliente: corregir UAF en descifrado asíncrono"), los canales comenzaron a reutilizar AEAD TFM del canal principal para realizar un descifrado sincrónico, pero eso no se puede hacer ya que podría haber varios subprocesos cifsd (uno por canal) accediendo simultáneamente a él para realizar el descifrado. Esto corrige el siguiente splat de KASAN al ejecutar fstest generic/249 con 'vers=3.1.1,multichannel,max_channels=4,seal' en Windows Server 2022: ERROR: KASAN: slab-use-after-free en gf128mul_4k_lle+0xba/0x110 Lectura de tamaño 8 en la dirección ffff8881046c18a0 por la tarea cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd No contaminado 6.15.0-rc1 #1 PREEMPT(voluntario) Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: ignorar xattrs después del final Una vez dentro de 'ext4_xattr_inode_dec_ref_all' debemos ignorar las entradas xattrs más allá de la entrada 'end'. Esto corrige el siguiente problema informado por KASAN: ====================================================================== ERROR: KASAN: slab-use-after-free en ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 Lectura de tamaño 4 en la dirección ffff888012c120c4 por la tarea repro/2065 CPU: 1 UID: 0 PID: 2065 Comm: repro No contaminado 6.13.0-rc2+ #11 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x1fd/0x300 ? tcp_gro_dev_warn+0x260/0x260 ? _printk+0xc0/0x100 ? read_lock_is_recursive+0x10/0x10 ? irq_work_queue+0x72/0xf0 ? __virt_addr_valid+0x17b/0x4b0 print_address_description+0x78/0x390 print_report+0x107/0x1f0 ? __virt_addr_valid+0x17b/0x4b0 ? __virt_addr_valid+0x3ff/0x4b0 ? __phys_addr+0xb5/0x160 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 kasan_report+0xcc/0x100 ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ext4_xattr_inode_dec_ref_all+0xb8c/0xe90 ? ext4_xattr_delete_inode+0xd30/0xd30 ? __ext4_journal_ensure_credits+0x5f0/0x5f0 ? __ext4_journal_ensure_credits+0x2b/0x5f0 ? inode_update_timestamps+0x410/0x410 ext4_xattr_delete_inode+0xb64/0xd30 ? ext4_truncate+0xb70/0xdc0 ? ext4_expand_extra_isize_ea+0x1d20/0x1d20 ? __ext4_mark_inode_dirty+0x670/0x670 ? ext4_journal_check_start+0x16f/0x240 ? ext4_inode_is_fast_symlink+0x2f2/0x3a0 ext4_evict_inode+0xc8c/0xff0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 ? do_raw_spin_unlock+0x53/0x8a0 ? ext4_inode_is_fast_symlink+0x3a0/0x3a0 evict+0x4ac/0x950 ? proc_nr_inodes+0x310/0x310 ? trace_ext4_drop_inode+0xa2/0x220 ? _raw_spin_unlock+0x1a/0x30 ? iput+0x4cb/0x7e0 do_unlinkat+0x495/0x7c0 ? try_break_deleg+0x120/0x120 ? 0xffffffff81000000 ? __check_object_size+0x15a/0x210 ? strncpy_from_user+0x13e/0x250 ? getname_flags+0x1dc/0x530 __x64_sys_unlinkat+0xc8/0xf0 do_syscall_64+0x65/0x110 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x434ffd Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8 RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107 RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001 La dirección con errores pertenece al objeto en ffff888012c12000 que pertenece al filp de caché de tamaño 360 La dirección con errores se encuentra 196 bytes dentro de la región liberada de 360 bytes [ffff888012c12000, ffff888012c12168) La dirección con errores pertenece a la página física: page: refcount:1 mapcount:0 mapping:000000000000000 index:0x0 pfn:0x12c12 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 conteo de pines:0 indicadores: 0x40(cabeza|nodo=0|zona=0) tipo_de_página: f5(losa) sin procesar: 0000000000000040 ffff888000ad7640 ffffea0000497a00 muerto000000000004 sin procesar: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 cabeza: 0000000000000040 ffff888000ad7640 ffffea0000497a00 muerto000000000004 cabeza: 0000000000000000 0000000000100010 00000001f5000000 00000000000000000 cabeza: 0000000000000001 ffffea00004b0481 ffffffffffffffff 000000000000000 cabeza: 0000000000000002 000000000000000 00000000ffffffff 000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto Estado de la memoria alrededor de la dirección con errores: ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Se corrige el acceso a un valor no inicializado de imap asignado en la función diMount() syzbot informa que hex_dump_to_buffer está usando un valor no inicializado: ======================================================== ERROR: KMSAN: un valor no inicializado en hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171 print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276 diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876 jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156 evict+0x723/0xd10 fs/inode.c:796 iput_final fs/inode.c:1946 [en línea] iput+0x97b/0xdb0 fs/inode.c:1972 txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [en línea] jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733 kthread+0x6b9/0xef0 kernel/kthread.c:464 ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Uninit se creó en: slab_post_alloc_hook mm/slub.c:4121 [en línea] slab_alloc_node mm/slub.c:4164 [en línea] __kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320 kmalloc_noprof include/linux/slab.h:901 [en línea] diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105 jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176 jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523 obtener_árbol_bdev_flags+0x6ec/0x910 fs/super.c:1636 obtener_árbol_bdev+0x37/0x50 fs/super.c:1659 jfs_obtener_árbol+0x34/0x40 fs/jfs/super.c:635 vfs_obtener_árbol+0xb1/0x5a0 fs/super.c:1814 hacer_nuevo_montaje+0x71f/0x15e0 fs/espacio_de_nombres.c:3560 path_mount+0x742/0x1f10 fs/namespace.c:3887 do_mount fs/namespace.c:3900 [en línea] __do_sys_mount fs/namespace.c:4111 [en línea] __se_sys_mount+0x71f/0x800 fs/namespace.c:4088 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4088 x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: Impide la copia de nlink con valor 0 desde el inodo de disco. syzbot informa de un bloqueo en diFree. [1] Al llamar a "ioctl$LOOP_SET_STATUS64", el valor de desplazamiento pasado es 4, que no coincide con el dispositivo de bucle montado, lo que invalida la asignación de dicho dispositivo. Al crear el directorio y el inodo de iag en diReadSpecial(), al leer la página del inodo de disco fijo (AIT) en modo sin procesar en read_metapage(), los datos de metapágina que devuelve están dañados, lo que provoca que el valor nlink de 0 se asigne al inodo iag al ejecutar copy_from_dinode(), lo que finalmente provoca un bloqueo al acceder a diFree(). Para evitar esto, compruebe primero el valor nlink de dinode antes de configurar el inodo iag. [1] ADVERTENCIA: se detectó un posible bloqueo recursivo 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 No contaminado -------------------------------------------- syz-executor301/5309 está intentando adquirir el bloqueo: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, en: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 pero la tarea ya tiene el bloqueo: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, en: diAlloc+0x1b6/0x1630 Otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- bloqueo(&(imap->im_aglock[índice])); bloqueo(&(imap->im_aglock[índice])); *** BLOQUEO INTERMEDIO *** Puede deberse a la falta de notación de anidamiento de bloqueos. 5 bloqueos mantenidos por syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, en: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, en: inode_lock_nested include/linux/fs.h:850 [en línea] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, en: nombre_archivo_crear+0x260/0x540 fs/nombrei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[índice])){+.+.}-{3:3}, en: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, en: diNewIAG fs/jfs/jfs_imap.c:2460 [en línea] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, en: diAllocExt fs/jfs/jfs_imap.c:1905 [en línea] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, en: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, en: diNewIAG fs/jfs/jfs_imap.c:2477 [en línea] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, en: diAllocExt fs/jfs/jfs_imap.c:1905 [en línea] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, en: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669 seguimiento de pila: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 No contaminado 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #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 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [en línea] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [en línea] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [en línea] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [en línea] diAllocExt fs/jfs/jfs_imap.c:1905 [en línea] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [en línea] __se_sys_mkdirat fs/namei.c:4293 [en línea] __x64_sys_mkdirat+0x87/0xa0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: añadir una comprobación de validez para agwidth en dbMount. El ancho en dmapctl del AG es cero, lo que genera un error de división al calcular el nivel de página de control en dbAllocAG. Para evitar este problema, añada una comprobación para agwidth en dbAllocAG.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar el acceso fuera de los límites en f2fs_truncate_inode_blocks() syzbot informa un problema de UBSAN como se muestra a continuación: ------------[ cortar aquí ]------------ UBSAN: array-index-out-of-bounds en fs/f2fs/node.h:381:10 el índice 18446744073709550692 está fuera de rango para el tipo '__le32[5]' (también conocido como 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 No contaminado 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [en línea] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/archivo.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/archivo.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/archivo.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [en línea] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 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 RIP: 0033:0x7f238798cde9 índice 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long) En f2fs_truncate_inode_blocks(), UBSAN detecta que get_nid() intenta acceder a .i_nid[-924], lo que significa que tanto offset[0] como level deben ser cero. El caso posible debería estar en f2fs_do_truncate_blocks(), tratamos de truncar el tamaño del inodo a cero, sin embargo, dn.ofs_in_node es cero y dn.node_page no es una página de inodo, por lo que no puede truncar la página de inodo y luego pasa free_from en cero a f2fs_truncate_inode_blocks(), lo que da como resultado este problema. if (dn.ofs_in_node || IS_INODE(dn.node_page)) { f2fs_truncate_data_blocks_range(&dn, count); free_from += count; } Supongo que la razón por la que dn.node_page no es una página de inodo podría ser: hay varias entradas nat que comparten la misma dirección de bloque de nodo, una vez que se reutilizó la dirección de bloque de nodo, f2fs_get_node_page() puede cargar un bloque que no sea de inodo. Agreguemos una verificación de cordura para tal condición para evitar problemas de acceso fuera de los límites.