Vulnerabilidades

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: um: ubd: No utilizar drvdata en la versión El archivo drvdata no está disponible en la versión. Simplemente usemos contenedor_of() para obtener la instancia ubd. De lo contrario, eliminar un dispositivo ubd provocará un bloqueo: RIP: 0033:blk_mq_free_tag_set+0x1f/0xba RSP: 00000000e2083bf0 EFLAGS: 00010246 RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00 RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348 RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7 R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000 R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0 Pánico del núcleo: no se sincroniza: error de segmentación sin mm CPU: 0 PID: 17 Comm: kworker/0:1 No contaminado 6.8.0-rc3-00107-gba3f67c11638 #1 Cola de trabajo: eventos mc_work_proc Pila: 00000000 604f7ef0 Rastreo de llamadas: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? mconsole_reply+0x0/0x50 [<6002b926>] mconsole_remove+0x160/0x1cc [<6002bbbc>] ? __schedule+0x0/0x3ed [<60033761>] ? um_set_signals+0x0/0x43 [<6002af6a>] mc_work_proc+0x77/0x91 [<600520b4>] proceso_trabajos_programados+0x1af/0x2c3 [<6004ede3>] ? asignar_trabajo+0x0/0x58 [<600527a1>] subproceso_trabajador+0x2f7/0x37a [<6004ee3b>] ? establecer_pf_trabajador+0x0/0x64 [<6005765d>] ? guardar_irq_local_arch+0x0/0x2d [<60058e07>] ? salir_kthread+0x0/0x3a [<600524aa>] ? subproceso_de_trabajo+0x0/0x37a [<60058f9f>] subproceso_de_trabajo+0x130/0x135 [<6002068e>] nuevo_controlador_de_subprocesos+0x85/0xb6

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "block, bfq: merge bfq_release_process_ref() into bfq_put_cooperator()" Esto revierte el commit bc3b1e9e7c50e1de0f573eea3871db61dd4787de. El bic está asociado con sync_bfqq y bfq_release_process_ref no se puede colocar en bfq_put_cooperator. informe de kasan: [ 400.347277] ======================================================================= [ 400.347287] ERROR: KASAN: slab-use-after-free en bic_set_bfqq+0x200/0x230 [ 400.347420] Lectura de tamaño 8 en la dirección ffff88881cab7d60 por la tarea dockerd/5800 [ 400.347430] [ 400.347436] CPU: 24 UID: 0 PID: 5800 Comm: dockerd Kdump: cargado Tainted: GE 6.12.0 #32 [ 400.347450] Contaminado: [E]=UNSIGNED_MODULE [ 400.347454] Nombre del hardware: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 28/07/2022 [ 400.347460] Seguimiento de llamadas: [ 400.347464] [ 400.347468] dump_stack_lvl+0x5d/0x80 [ 400.347490] print_report+0x174/0x505 [ 400.347521] kasan_report+0xe0/0x160 [ 400.347541] bic_set_bfqq+0x200/0x230 [ 400.347549] bfq_bic_update_cgroup+0x419/0x740 [ 400.347560] bfq_bio_merge+0x133/0x320 [ 400.347584] blk_mq_submit_bio+0x1761/0x1e20 [ 400.347625] __submit_bio+0x28b/0x7b0 [ 400.347664] enviar_bio_noacct_nocheck+0x6b2/0xd30 [ 400.347690] iomap_readahead+0x50c/0x680 [ 400.347731] páginas_de_lectura+0x17f/0x9c0 [ 400.347785] caché_de_página_ra_sin_límites+0x366/0x4a0 [ 400.347795] error_mapa_archivo+0x83d/0x2340 [ 400.347819] error_mapa_archivo_xfs+0x11a/0x7d0 [xfs] [ 400.349256] error_do+0xf1/0x610 [ 400.349270] error_do+0x977/0x11a0 [ 400.349281] error_mm_gestionar+0x5d1/0x850 [ 400.349314] handle_mm_fault+0x1f8/0x560 [ 400.349324] do_user_addr_fault+0x324/0x970 [ 400.349337] exc_page_fault+0x76/0xf0 [ 400.349350] asm_exc_page_fault+0x26/0x30 [ 400.349360] RIP: 0033:0x55a480d77375 [ 400.349384] Código: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 3b 66 10 0f 86 ae 02 00 00 55 48 89 e5 48 83 ec 58 48 8b 10 <83> 7a 10 00 0f 84 27 02 00 00 44 0f b6 42 28 44 0f b6 4a 29 41 80 [ 400.349392] RSP: 002b:00007f18c37fd8b8 EFLAGS: 00010216 [ 400.349401] RAX: 00007f18c37fd9d0 RBX: 000000000000000 RCX: 0000000000000000 [ 400.349407] RDX: 000055a484407d38 RSI: 000000c000e8b0c0 RDI: 0000000000000000 [ 400.349412] RBP: 00007f18c37fd910 R08: 000055a484017f60 R09: 000055a484066f80 [ 400.349417] R10: 0000000000194000 R11: 0000000000000005 R12: 0000000000000008 [ 400.349422] R13: 0000000000000000 R14: 000000c000476a80 R15: 0000000000000000 [ 400.349430] [ 400.349452] [ 400.349454] Asignado por la tarea 5800: [ 400.349459] kasan_save_stack+0x30/0x50 [ 400.349469] kasan_save_track+0x14/0x30 [ 400.349475] __kasan_slab_alloc+0x89/0x90 [ 400.349482] kmem_cache_alloc_node_noprof+0xdc/0x2a0 [ 400.349492] bfq_get_queue+0x1ef/0x1100 [ 400.349502] __bfq_get_bfqq_handle_split+0x11a/0x510 [ 400.349511] bfq_insert_requests+0xf55/0x9030 [ 400.349519] blk_mq_flush_plug_list+0x446/0x14c0 [ 400.349527] __blk_flush_plug+0x27c/0x4e0 [ 400.349534] blk_finish_plug+0x52/0xa0 [ 400.349540] _xfs_buf_ioapply+0x739/0xc30 [xfs] [ 400.350246] __xfs_buf_submit+0x1b2/0x640 [xfs] [ 400.350967] xfs_buf_read_map+0x306/0xa20 [xfs] [ 400.351672] xfs_trans_read_buf_map+0x285/0x7d0 [xfs] [ 400.352386] xfs_imap_to_bp+0x107/0x270 [xfs] [ 400.353077] xfs_iget+0x70d/0x1eb0 [xfs] [ 400.353786] xfs_lookup+0x2ca/0x3a0 [xfs] [ 400.354506] xfs_vn_lookup+0x14e/0x1a0 [xfs] [ 400.355197] __lookup_slow+0x19c/0x340 [ 400.355204] lookup_one_unlocked+0xfc/0x120 [ 400.355211] ovl_lookup_single+0x1b3/0xcf0 [superposición] [ 400.355255] ovl_lookup_layer+0x316/0x490 [superposición] [ 400.355295] ovl_lookup+0x844/0x1fd0 [superposición] [ 400.355351] lookup_one_qstr_excl+0xef/0x150 [ 400.355357] do_unlinkat+0x22a/0x620 [ 400.355366] __x64_sys_unlinkat+0x109/0x1e0 [ 400.355375] do_syscall_64+0x82/0x160 [ 400.355384] entrada_SYSCALL_64_after_hwframe+0x76/0x7 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: evitar el use-after-free debido a las rutas de error de open_cached_dir Si open_cached_dir() encuentra un error al analizar el arrendamiento desde el servidor, la gestión de errores puede acelerarse con la recepción de una interrupción del arrendamiento, lo que da como resultado que open_cached_dir() libere el cfid mientras el trabajo en cola está pendiente. Actualice open_cached_dir() para eliminar referencias en lugar de liberar directamente el cfid. Haga que cached_dir_lease_break(), cfids_laundromat_worker() e invalidate_all_cached_dirs() borren has_lease inmediatamente mientras aún mantienen cfids->cfid_list_lock, y luego use esto para simplificar también el conteo de referencias en cfids_laundromat_worker() e invalidate_all_cached_dirs(). Corrige este problema de KASAN (que inyecta manualmente un error y una interrupción de arrendamiento en open_cached_dir()): ====================================================================== ERROR: KASAN: slab-use-after-free en smb2_cached_lease_break+0x27/0xb0 Lectura de tamaño 8 en la dirección ffff88811cc24c10 por la tarea kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 No contaminado 6.12.0-rc6-g255cf264e6e5-dirty #87 Nombre del hardware: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/11/2020 Cola de trabajo: cifsiod smb2_cached_lease_break Seguimiento de llamadas: dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Asignado por la tarea 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 directorio_caché_abierto+0xa7d/0x1fb0 información_ruta_consulta_smb2+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 información_inodo_obtener_cifs+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 ruta_statx_vfs+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Última creación de trabajo potencialmente relacionado: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 cola_trabajo_activada+0x82/0x90 directorio_caché_abierto+0x1369/0x1fb0 información_ruta_consulta_smb2+0x43c/0x6e0 cifs_obtener_fattr+0x346/0xf10 cifs_obtener_información_inodo+0x157/0x210 cifs_revalidar_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 ruta_statx_vfs+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e La dirección con errores pertenece al objeto en ffff88811cc24c00 que pertenece al caché kmalloc-1k de tamaño 1024 La dirección con errores se encuentra 16 bytes dentro de la región liberada de 1024 bytes [ffff88811cc24c00, ffff88811cc25000)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige el use-after-free de la clave de firma Los clientes han informado sobre el use-after-free en @ses->auth_key.response con SMB2.1 + montajes de firma que se producen debido a la siguiente ejecución: tarea A tarea B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() Compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Solucione esto asegurándose de que tenemos un @ses->auth_key.response válido comprobando si @ses->ses_status es SES_GOOD o SES_EXITING con @ses->ses_lock Después de el commit 24a9799aa8ef ("smb: cliente: corregir UAF en smb2_reconnect_server()"), nos aseguramos de llamar a ->logoff() solo cuando se sabía que @ses era correcto (por ejemplo, ->auth_key.response válido), por lo que es seguro acceder a la clave de firma cuando @ses->ses_status == SES_EXITING.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corregir NULL ptr deref en crypto_aead_setkey() Ni SMB3.0 ni SMB3.02 admiten el contexto de negociación de cifrado, por lo que cuando se establece el indicador SMB2_GLOBAL_CAP_ENCRYPTION en la respuesta de negociación, el cliente utiliza AES-128-CCM como cifrado predeterminado. Consulte MS-SMB2 3.3.5.4. el commit b0abcd65ec54 ("smb: cliente: corregir UAF en descifrado asíncrono") agregó una comprobación @server->cipher_type para llamar condicionalmente a smb3_crypto_aead_allocate(), pero esa comprobación siempre sería falsa ya que @server->cipher_type no está configurado para SMB3.02. Corrija el siguiente splat de KASAN configurando también @server->cipher_type para SMB3.02. mount.cifs //srv/share /mnt -o vers=3.02,seal,... ERROR: KASAN: null-ptr-deref en crypto_aead_setkey+0x2c/0x130 Lectura de tamaño 8 en la dirección 0000000000000020 por la tarea mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs No contaminado 6.12.0 #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Rastreo de llamadas: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compuesto_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? bloqueo_adquirir.parte.0+0xf4/0x2a0 ? bloqueo_adquirir+0xc6/0x120 ? _get_xid+0x16/0xd0 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? bloqueo_adquirir.parte.0+0xf4/0x2a0 ? bloqueo_retenido_encontrar+0x8a/0xa0 ? clase_bloqueo_h+0x32/0xb0 ? liberación_bloqueo+0x203/0x5d0 montaje_cifs+0xb3/0x3d0 [cifs] ? intento_bloqueo_giro_sin_bloqueo+0xc6/0x120 ? montaje_cifs_pfx+0x10/0x10 [cifs] ? bloqueo_adquirir+0x3f/0x90 ? montaje_nls_encontrar+0x16/0xa0 ? banderas_mnt_actualizar_smb3+0x372/0x3b0 [cifs] cifs_smb3_hacer_montar+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? marcar_bloqueos_retenidos+0x1a/0x90 hacer_llamada_al_sistema_64+0xbb/0x1d0 entrada_SYSCALL_64_después_de_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: No filtrar cfid cuando la reconexión compite con open_cached_dir open_cached_dir() puede competir con la reconexión tcon incluso antes de Compound_send_recv() o activar directamente una reconexión a través de SMB2_open_init() o SMB_query_info_init(). El proceso de reconexión invoca invalidate_all_cached_dirs() a través de cifs_mark_open_files_invalid(), que elimina todos los cfids de la lista cfids->entries pero no elimina una referencia si has_lease no es verdadero. Esto da como resultado que el cfid que se está construyendo actualmente no esté en la lista, pero aún tenga un recuento de referencias de 2. Se filtra si se devuelve desde open_cached_dir(). Solucione esto configurando cfid->has_lease cuando la referencia se toma realmente; el cfid no será utilizado por otros subprocesos hasta que tenga un tiempo válido. Aborda estos kmemleaks: objeto sin referencia 0xffff8881090c4000 (tamaño 1024): comm "bash", pid 1860, jiffies 4295126592 volcado hexadecimal (primeros 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de .........."....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"...O..... backtrace (crc 6f58c20f): [] __kmalloc_cache_noprof+0x2be/0x350 [] directorio_caché_abierto+0x993/0x1fb0 [] directorio_lectura_cifs+0x15a0/0x1d50 [] directorio_iteración+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] llamada_al_sistema_64+0x95/0x1a0 [] entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e objeto sin referencia 0xffff8881044fdcf8 (tamaño 8): comm "bash", pid 1860, jiffies 4295126592 volcado hexadecimal (primeros 8 bytes): 00 cc cc cc cc cc cc cc cc ........ seguimiento inverso (crc 10c106a9): [] __kmalloc_node_track_caller_noprof+0x363/0x480 [] kstrdup+0x36/0x60 [] open_cached_dir+0x9b0/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e Y soluciona estos errores al desmontar el sistema de archivos SMB: ERROR: Dentry ffff888140590ba0{i=1000000000080,n=/} todavía en uso (2) [desmontaje de cifs cifs] ADVERTENCIA: CPU: 3 PID: 3433 en fs/dcache.c:1536 umount_check+0xd0/0x100 Módulos vinculados: CPU: 3 UID: 0 PID: 3433 Comm: bash No contaminado 6.12.0-rc4-g850925a8133c-dirty #49 Nombre del hardware: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/11/2020 RIP: 0010:umount_check+0xd0/0x100 Código: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41 RSP: 0018:ffff88811cc27978 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: fffffffaaf20bae RDX: dffffc0000000000 RSI: 00000000000000008 RDI: ffff8881f6fb6f40 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3 R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08 R13: 00000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0 FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0 Seguimiento de llamadas: d_walk+0x6a/0x530 encoger_dcache_for_umount+0x6a/0x200 apagado_genérico_super+0x52/0x2a0 matar_anónimo_super+0x22/0x40 matar_sb_cifs+0x159/0x1e0 desactivar_bloqueado_super+0x66/0xe0 desinfección_mnt+0x140/0x210 ejecución_trabajo_tarea+0xfb/0x170 salida_llamada_al_sistema_al_modo_usuario+0x29f/0x2b0 llamada_al_sistema_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Código: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipc: se corrige la fuga de memoria si msg_init_ns falla en create_ipc_ns. La asignación de memoria por CPU puede fallar durante create_ipc_ns; sin embargo, este error no se gestiona correctamente, ya que ipc sysctls y mq sysctls no se liberan correctamente. Solucione esto liberando estos dos recursos cuando falle. Aquí está la pila kmemleak cuando percpu falló: objeto sin referencia 0xffff88819de2a600 (tamaño 512): comm "shmem_2nstest", pid 120711, jiffies 4300542254 volcado hexadecimal (primeros 32 bytes): 60 aa 9d 84 ff ff ff ff ff fc 18 48 b2 84 88 ff ff `.........H..... 04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff ........ .V..... backtrace (crc be7cba35): [] __kmalloc_node_track_caller_noprof+0x333/0x420 [] kmemdup_noprof+0x26/0x50 [] configuración_mq_sysctls+0x57/0x1d0 [] copia_ipcs+0x29c/0x3b0 [] creación_nuevos_espacios_de_nombres+0x1d0/0x920 [] copia_espacios_de_nombres+0x2e9/0x3e0 [] proceso_de_copia+0x29f3/0x7ff0 [] clon_de_kernel+0xc0/0x650 [] __do_sys_clone+0xa1/0xe0 [] hacer_llamada_al_sistema_64+0xbf/0x1c0 [] entrada_LLAMADA_AL_SISTEMA_64_después_de_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubi: fastmap: corrige nombres de caché de slab duplicados al adjuntar Desde el commit 4c39529663b9 ("slab: Advertir sobre nombres de caché duplicados cuando DEBUG_VM=y"), se pueden detectar los nombres de caché de slab duplicados y se emite una ADVERTENCIA del kernel. En el proceso de conexión rápida de UBI, alloc_ai() podría invocarse dos veces con el mismo nombre de caché de losa 'ubi_aeb_slab_cache', lo que activará los siguientes mensajes de advertencia: kmem_cache con el nombre 'ubi_aeb_slab_cache' ya existe ADVERTENCIA: CPU: 0 PID: 7519 en mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Módulos vinculados en: ubi(+) nandsim [última descarga: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Rastreo de llamadas: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0 El problema se puede reproducir fácilmente cargando el dispositivo UBI mediante fastmap con CONFIG_DEBUG_VM=y. Arréglelo utilizando diferentes nombres de losa para los invocadores de alloc_ai().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: Durante el desmontaje, asegurarse de que todas las instancias de directorio en caché eliminen su dentry El proceso de desmontaje (cifs_kill_sb() llamando a close_all_cached_dirs()) puede competir con varias operaciones de directorio en caché, lo que en última instancia da como resultado que no se eliminen los dentries y estos ERRORES del kernel: ERROR: Dentry ffff88814f37e358{i=1000000000080,n=/} todavía en uso (2) [desmontaje de cifs cifs] VFS: Inodos ocupados después del desmontaje de cifs (cifs) ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/super.c:661! Esto sucede cuando un cfid está en proceso de desinfección y se ha eliminado de la lista cfids->entries, lo que incluye: - Recibir una interrupción de arrendamiento del servidor - La reconexión del servidor activa invalidate_all_cached_dirs(), que elimina todos los cfids de la lista - El hilo de la lavandería decide hacer caducar un cfid antiguo. Para resolver estos problemas, se elimina el dentry en el trabajo en cola realizado en una cola de trabajo cfid_put_wq recién agregada, y close_all_cached_dirs() vacía esa cola de trabajo después de eliminar todos los dentries de los que tiene conocimiento. Esta es una cola de trabajo global (en lugar de tener un alcance de montaje), pero el trabajo en cola es mínimo. El trabajo de desinfección final para limpiar un cfid se realiza a través del trabajo en cola en la cola de trabajo serverclose_wq; esto se hace por separado de la eliminación de los dentries para que close_all_cached_dirs() no bloquee ninguna operación del servidor. Se espera que ambos trabajos en cola se invoquen con una referencia cfid y una referencia tcon para evitar que esos objetos se liberen mientras el trabajo está en curso. Mientras estamos aquí, agregue un bloqueo adecuado a close_all_cached_dirs() y un bloqueo alrededor de la liberación de cfid->dentry.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: asegúrese de que la entrada de caché esté activa antes de cache_show La función `c_show` se llamó con protección de RCU. Esto solo garantiza que `cp` no se liberará. Por lo tanto, el recuento de referencia para `cp` puede caer a cero, lo que activará una advertencia de use-after-free de refcount cuando se llame a `cache_get`. Para resolver este problema, use `cache_get_rcu` para asegurarse de que `cp` permanezca activo. ------------[ cortar aquí ]------------ refcount_t: adición en 0; use-after-free. ADVERTENCIA: CPU: 7 PID: 822 en lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat No contaminado 6.12.0-rc3+ #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Seguimiento de llamadas: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 hacer_syscall_64+0x5f/0x170 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir uaf para flush rq mientras se itera etiquetas blk_mq_clear_flush_rq_mapping() no se llama durante la sonda scsi, al verificar blk_queue_init_done(). Sin embargo, QUEUE_FLAG_INIT_DONE se borra en del_gendisk por el commit aec89dc5d421 ("bloque: mantener q_usage_counter en modo atómico después de del_gendisk"), por lo tanto, para discos como scsi, seguir blk_mq_destroy_queue() tampoco borrará el flush rq de tags->rqs[], debido al siguiente uaf que nuestro syzkaller encuentra para v6.6: ===================================================================== ERROR: KASAN: slab-use-after-free en blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 Lectura de tamaño 4 en la dirección ffff88811c969c20 por la tarea kworker/1:2H/224909 CPU: 1 PID: 224909 Comm: kworker/1:2H No contaminado 6.6.0-ga836a5060850 #32 Cola de trabajo: kblockd blk_mq_timeout_work Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364 print_report+0x3e/0x70 mm/kasan/report.c:475 kasan_report+0xb8/0xf0 mm/kasan/report.c:588 blk_mq_find_and_get_req+0x16e/0x1a0 bloque/blk-mq-tag.c:261 bt_iter bloque/blk-mq-tag.c:288 [en línea] __sbitmap_for_each_set include/linux/sbitmap.h:295 [en línea] sbitmap_for_each_set include/linux/sbitmap.h:316 [en línea] bt_for_each+0x455/0x790 bloque/blk-mq-tag.c:325 blk_mq_queue_tag_busy_iter+0x320/0x740 bloque/blk-mq-tag.c:534 blk_mq_timeout_work+0x1a3/0x7b0 bloque/blk-mq.c:1673 proceso_uno_trabajo+0x7c4/0x1450 kernel/workqueue.c:2631 proceso_trabajos_programados kernel/workqueue.c:2704 [en línea] subproceso_trabajador+0x804/0xe40 kernel/workqueue.c:2785 subproceso_k+0x346/0x450 kernel/kthread.c:388 ret_de_bifurcación+0x4d/0x80 arch/x86/kernel/process.c:147 ret_de_bifurcación_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293 Asignado por la tarea 942: pila_guardada_kasan+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [en línea] __kasan_kmalloc mm/kasan/common.c:383 [en línea] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasan_kmalloc include/linux/kasan.h:198 [en línea] __do_kmalloc_node mm/slab_common.c:1007 [en línea] __kmalloc_node+0x69/0x170 mm/slab_common.c:1014 kmalloc_node include/linux/slab.h:620 [en línea] kzalloc_node include/linux/slab.h:732 [en línea] blk_alloc_flush_queue+0x144/0x2f0 bloque/blk-flush.c:499 blk_mq_alloc_hctx+0x601/0x940 bloque/blk-mq.c:3788 blk_mq_alloc_and_init_hctx+0x27f/0x330 bloque/blk-mq.c:4261 blk_mq_realloc_hw_ctxs+0x488/0x5e0 bloque/blk-mq.c:4294 blk_mq_init_allocated_queue+0x188/0x860 bloque/blk-mq.c:4350 blk_mq_init_queue_data bloque/blk-mq.c:4166 [en línea] blk_mq_init_queue+0x8d/0x100 block/blk-mq.c:4176 scsi_alloc_sdev+0x843/0xd50 drivers/scsi/scsi_scan.c:335 scsi_probe_and_add_lun+0x77c/0xde0 drivers/scsi/scsi_scan.c:1189 __scsi_scan_target+0x1fc/0x5a0 drivers/scsi/scsi_scan.c:1727 scsi_scan_channel drivers/scsi/scsi_scan.c:1815 [en línea] scsi_scan_channel+0x14b/0x1e0 drivers/scsi/scsi_scan.c:1791 scsi_scan_host_selected+0x2fe/0x400 drivers/scsi/scsi_scan.c:1844 scsi_scan+0x3a0/0x3f0 drivers/scsi/scsi_sysfs.c:151 store_scan+0x2a/0x60 drivers/scsi/scsi_sysfs.c:191 dev_attr_store+0x5c/0x90 drivers/base/core.c:2388 sysfs_kf_write+0x11c/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x3fc/0x610 fs/kernfs/file.c:338 call_write_iter include/linux/fs.h:2083 [en línea] new_sync_write+0x1b4/0x2d0 fs/read_write.c:493 vfs_write+0x76c/0xb00 fs/read_write.c:586 ksys_write+0x127/0x250 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [en línea] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Liberado por la tarea 244687: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 --truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: authentication: Fix use-after-free en ubifs_tnc_end_commit Después de una inserción en TNC, el árbol podría dividirse y hacer que un nodo cambie su `znode->parent`. Una eliminación adicional de otros nodos en el árbol (que también podría liberar los nodos), el `znode->cparent` del nodo mencionado anteriormente aún podría apuntar a un nodo liberado. Este `znode->cparent` puede no actualizarse al hacer que los nodos se comprometan en `ubifs_tnc_start_commit()`. Esto podría desencadenar un use-after-free al acceder a `znode->cparent` en `write_index()` en `ubifs_tnc_end_commit()`. Esto se puede activar ejecutando rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync en un bucle y con `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN luego informa: ERROR: KASAN: use-after-free en ubifs_tnc_end_commit+0xa5c/0x1950 Escritura de tamaño 32 en la dirección ffffff800a3af86c por la tarea ubifs_bgt0_20/153 Rastreo de llamadas: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 Asignado por la tarea 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 escritura_caché_páginas+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c intervalo_de_escritura_y_espera_de_archivo+0x140/0x190 ubifs_fsync+0xe8/0x290 intervalo_de_fsync_vfs+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invocar_llamada_al_sistema.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 Liberado por la tarea 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 El `memcpy()` ofensivo en `ubifs_copy_hash()` tiene un use-after-free cuando un nodo se convierte en raíz en TNC pero aún tiene un `cparent` para un nodo ya liberado. Más específicamente, considere la siguiente TNC: zroot // zp1 // zn Insertar un nuevo nodo `zn_new` con una clave menor que `zn` activará una división en `tnc_insert()` si `zp1` está lleno: zroot / \ / \ zp1 zp2 / \ / \ zn_new zn `zn->parent` ahora se ha movido a `zp2`, *pero* `zn->cparent` todavía apunta a `zp1`. Ahora, considere una eliminación de todos los nodos _excepto_ `zn`. Justo cuando `tnc_delete()` está a punto de eliminar `zroot` y `zp2`: zroot \ \ zp2 \ \ zn `zroot` y `zp2` se liberan y el árbol colapsa: zn `zn` ahora se convierte en el nuevo `zroot`. `get_znodes_to_commit()` ahora solo encontrará `zn`, el nuevo `zroot`, y `write_index()` verificará su `znode->cparent` que apunta erróneamente al `zp1` ya liberado. Por lo tanto, `ubifs_copy_hash()` se llama erróneamente con `znode->cparent->zbranch[znode->iip].hash` que activa el use-after-free. Solucione esto configurando explícitamente `znode->cparent` en `NULL` en `get_znodes_to_commit()` para el nodo raíz. La búsqueda de los nodos sucios ---truncada---