Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: No importar certificados desde UEFI Secure Boot para Mac T2 En Mac T2 de Apple, cuando Linux intenta leer las variables efi db y dbx en el arranque temprano para cargar certificados UEFI Secure Boot, se produce un error de página en el código de firmware de Apple y los servicios de tiempo de ejecución de EFI se desactivan con los siguientes registros: [Error de firmware]: Error de página causado por el firmware en PA: 0xffffb1edc0068000 ADVERTENCIA: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 De esta forma evitamos leer estas variables UEFI y, por lo tanto, evitamos el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: regla de flujo de memleak de la ruta de confirmación. La ruta de cancelación libera el objeto de regla de flujo, pero la ruta de confirmación no lo hace. Actualice el código para destruir estos objetos antes de liberar la transacción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en total_data_blocks Como informó Yanming en Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215916 El mensaje del kernel se muestra a continuación: ¡ERROR del kernel en fs/f2fs/segment.c:2560! Call Trace: allocate_segment_by_default+0x228/0x440 f2fs_allocate_data_block+0x13d1/0x31f0 do_write_page+0x18d/0x710 f2fs_outplace_write_data+0x151/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0x3bc0 f2fs_balance_fs+0x921/0x2260 f2fs_write_single_data_page+0x16be/0x2370 f2fs_write_cache_pages+0x428/0xd00 f2fs_write_data_pages+0x96e/0xd50 do_writepages+0x168/0x550 __writeback_single_inode+0x9f/0x870 writeback_sb_inodes+0x47d/0xb20 __writeback_inodes_wb+0xb2/0x200 wb_writeback+0x4bd/0x660 wb_workfn+0x5f3/0xab0 process_one_work+0x79f/0x13e0 worker_thread+0x89/0xf60 kthread+0x26a/0x300 ret_from_fork+0x22/0x30 RIP: 0010:new_curseg+0xe8d/0x15f0 La causa raíz es: ckpt.valid_block_count es inconsistente con la tabla SIT, la información estadística indica que el sistema de archivos tiene bloques libres, pero la tabla SIT indica que el sistema de archivos no tiene segmentos libres. Por lo tanto, durante la recolección de basura, se genera un pánico cuando el asignador LFS no encuentra un segmento libre. Este parche intenta solucionar este problema al verificar la coherencia entre ckpt.valid_block_count y el bloque contabilizado desde SIT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura para el inodo en línea Yanming informó de un error del kernel en el kernel de Bugzilla [1], que se puede reproducir. El mensaje del error es: El mensaje del kernel se muestra a continuación: kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 dput+0x2dd/0x720 do_renameat2+0x596/0x970 __x64_sys_rename+0x78/0x90 do_syscall_64+0x3b/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 El error se debe a que el inodo fuzzed tiene indicadores inline_data y cifrados. Durante f2fs_evict_inode(), como el inodo fue eliminado por rename(), esto provocará una conversión de datos en línea debido a indicadores conflictivos. La caché de la página se contaminará y se activará el pánico en clear_inode(). Intente corregir el error realizando más comprobaciones de integridad para el inodo de datos en línea en sanity_check_inode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en la dirección de bloque en f2fs_do_zero_range() Como informó Yanming en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215894 He encontrado un error en el sistema de archivos F2FS en el kernel v5.17. He subido la secuencia de llamada del sistema como case.c, y se puede encontrar una imagen difusa en google net disk El kernel debe habilitar CONFIG_KASAN=y y CONFIG_KASAN_INLINE=y. Puede reproducir el error ejecutando los siguientes comandos: kernel BUG at fs/f2fs/segment.c:2291! Rastreo de llamadas: f2fs_invalidate_blocks+0x193/0x2d0 f2fs_fallocate+0x2593/0x4a70 vfs_fallocate+0x2a5/0xac0 ksys_fallocate+0x35/0x70 __x64_sys_fallocate+0x8e/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae La causa raíz es que, después de que se realizó el análisis difuso de la imagen, la información de mapeo de bloques en el inodo será inconsistente con la tabla SIT, por lo que en f2fs_fallocate(), causará pánico al actualizar SIT con blkaddr no válido. Solucionemos el problema agregando una verificación de cordura en la dirección del bloque antes de actualizar la tabla SIT con ella.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el use-after-free en ext4_rename_dir_prepare Tuvimos el siguiente problema: EXT4-fs (loop0): sistema de archivos montado sin diario. Opciones: ,errores=continuar ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae =================================================================== ERROR: KASAN: use-after-free en ext4_rename_dir_prepare+0x152/0x220 Lectura de tamaño 4 en la dirección ffff88810beee6ae por tarea rep/1895 CPU: 13 PID: 1895 Comm: rep No contaminado 5.10.0+ #241 Seguimiento de llamadas: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 La dirección con errores pertenece a la página: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 000000000000001 000000000000000 00000000ffffffff 000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección con errores: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ====================================================================== Desactivar bloqueo depuración debido a la corrupción del kernel ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 El motivo es que la primera entrada del directorio cuyo 'rec_len' es 34478, obtendrá una entrada principal ilegal. Ahora, no verificamos la entrada del directorio después de leer el bloque del directorio en 'ext4_get_first_dir_block'. Para resolver este problema, verifique la entrada del directorio en 'ext4_get_first_dir_block'. [ Active un ext4_error() en lugar de solo advertir si al directorio le falta una entrada '.' o '..'. También asegúrese de que devolvamos un código de error si el sistema de archivos está dañado. -¡ ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Se solucionó una ejecución de datos en unix_dgram_peer_wake_me(). unix_dgram_poll() llama a unix_dgram_peer_wake_me() sin el bloqueo de `other` y verifica si su cola de recepción está llena. Aquí necesitamos usar unix_recvq_full_lockless() en lugar de unix_recvq_full(), de lo contrario KCSAN informará una ejecución de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar ciclos en el directorio h-tree Un sistema de archivos dañado maliciosamente puede contener ciclos en el h-tree almacenados dentro de un directorio. Eso puede hacer que el kernel corrompa fácilmente los nodos del árbol que ya se habían verificado bajo su control mientras realizaba una división de nodos y, en consecuencia, accediera a memoria no asignada. Solucione el problema verificando que los números de bloque recorridos sean únicos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí la última para este caso porque el único sitio de llamada en el árbol, net/ipv4/xfrm4_policy.c nunca se compila como modular. (CONFIG_XFRM es booleano)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: lantiq_gswip: Se corrige la pérdida de recuento de referencias en gswip_gphy_fw_list Cada iteración de for_each_available_child_of_node() disminuye el recuento de referencias del nodo anterior. Al salir antes de un bucle for_each_available_child_of_node(), debemos llamar explícitamente a of_node_put() en gphy_fw_np. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de bug_on en ext4_writepages. Tenemos el siguiente problema: Error EXT4-fs (dispositivo loop0): ext4_mb_generate_buddy:1141: grupo 0, mapa de bits de bloque y descriptor de fondo inconsistentes: 25 frente a 31513 cls libres ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/ext4/inode.c:2708! código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep No contaminado 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 00000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 Puede suceder de la siguiente manera: 1. escribir inline_data inodo vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> Si el tamaño de los datos en línea es demasiado pequeño, se asignará un bloque para escribir, luego la asignación tendrá una página sucia ext4_da_convert_inline_data_to_extent -> borrar EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> falla irá a restaurar datos ext4_restore_inline_data ext4_crear_inline_data ext4_write_inline_data ext4_set_inode_state -> establecer inodo EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages si (ext4_has_inline_data(inodo)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) La causa principal de este problema es que destruimos los datos en línea hasta que llamamos a ext4_writepages en el modo de asignación de demora. Pero es posible que ya hayamos convertido de en línea a extendido. Para resolver este problema, primero llamamos a filemap_flush.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: filtrar EXT4_FC_REPLAY del campo s_state del superbloque en disco El bit EXT4_FC_REPLAY en sbi->s_mount_state se usa para indicar que estamos en medio de la reproducción del diario de confirmación rápida. En realidad, esto fue un error, ya que sbi->s_mount_info se inicializa desde es->s_state. Podría decirse que s_mount_state tiene un nombre engañoso, pero el nombre es histórico --- s_mount_state y s_state se remontan a ext2. Lo que se debería haber usado son las funciones en línea ext4_{set,clear,test}_mount_flag(), que establecen los bits EXT4_MF_* en sbi->s_mount_flags. El problema con el uso de EXT4_FC_REPLAY es que un superbloque dañado maliciosamente podría provocar que EXT4_FC_REPLAY se establezca en s_mount_state. Esto evita algunas comprobaciones de cordura y puede desencadenar un error en ext4_es_cache_extent(). Como solución fácil de implementar, filtre el bit EXT4_FC_REPLAY por ahora. Deberíamos dejar de usar EXT4_FC_REPLAY para pasar a algo como EXT4_MF_REPLAY.