Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_octeon_cf: se corrige la pérdida de recuento de referencias en octeon_cf_probe. La referencia que toma la función de _find_device_by_node() se debe liberar cuando ya no se necesite. Se agrega la función put_device() que falta para evitar la pérdida de recuento de referencias.

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Trampa desbordamientos de segmentos RDMA Impide que svc_rdma_build_writes() se aleje del final de la matriz de segmentos de un fragmento de escritura. Detectado con KASAN. La prueba que esta corrección reemplaza no es válida y podría haber quedado de un prototipo anterior del trabajo de PCL.

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)