Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc/libmasm/module: corrige dos use after free en ibmasm_init_one. En ibmasm_init_one, llama a ibmasm_init_remote_input_dev(). Dentro de ibmasm_init_remote_input_dev, mouse_dev y keybd_dev son asignados por input_allocate_device() y asignados a sp->remote.mouse_dev y sp->remote.keybd_dev respectivamente. En la rama de error err_free_devices de ibmasm_init_one, mouse_dev y keybd_dev se liberan mediante input_free_device() y devuelven un error. Luego, la ejecución se ejecuta en la rama de error error_send_message de ibmasm_init_one, donde se llama a ibmasm_free_remote_input_dev(sp) para cancelar el registro de sp->remote.mouse_dev y sp->remote.keybd_dev liberados. Mi parche agrega una etiqueta "error_init_remote" para manejar el error de ibmasm_init_remote_input_dev(), para evitar los errores de uaf.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: solución para evitar ejecuciónes en fsync_entry_slab por instancias de múltiples sistemas de archivos. Como informó syzbot, hay un problema de use after free durante la recuperación de f2fs: escritura de use after free en 0xffff88823bc16040 ( en kfence-#10): kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486 f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869 f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945 _bdev+0x26c /0x3a0 fs/super.c:1367 Legacy_get_tree+0xea/0x180 fs/fs_context.c:592 vfs_get_tree+0x86/0x270 fs/super.c:1497 do_new_mount fs/namespace.c:2905 [en línea] path_mount+0x196f/0x2be0 fs /namespace.c:3235 do_mount fs/namespace.c:3248 [en línea] __do_sys_mount fs/namespace.c:3456 [en línea] __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433 do_syscall_64+0x3f/0xb0 arch/x86/entry /common.c:47 Entry_SYSCALL_64_after_hwframe+0x44/0xae La causa principal es que varias instancias del sistema de archivos f2fs pueden acelerarse al acceder al puntero global fsync_entry_slab, lo que resulta en un problema de use after free del caché de slab, se corrige para iniciar/destruir este caché de slab solo una vez durante procedimiento de inicio/destrucción del módulo para evitar este problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smackfs: restringir el recuento de bytes en smk_set_cipso() Oops, no pude actualizar la línea de asunto. De 07571157c91b98ce1a4aa70967531e64b78e8346 lunes 17 de septiembre 00:00:00 2001 Fecha: lunes 12 de abril de 2021 22:25:06 +0900 Asunto: [PATCH] smackfs: restringir el recuento de bytes en smk_set_cipso() Confirmación 7ef4c1 9d245f3dc2 ("smackfs: restringir el recuento de bytes en smackfs funciones de escritura") perdió ese recuento > La verificación SMK_CIPSOMAX se aplica solo al formato == caso SMK_FIXED24_FMT.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: core: corrige la desreferencia del puntero incorrecto cuando ehandler kthread no es válido. La confirmación 66a834d09293 ("scsi: core: corrige el manejo de errores de scsi_host_alloc()") cambió la lógica de asignación para llamar a put_device( ) para realizar la limpieza del host asumiendo que la eliminación de IDA y la detención del kthread se realizarían correctamente en scsi_host_dev_release(). Sin embargo, en el improbable caso de que el subproceso del controlador de errores no se genere, shost->ehandler se establece en ERR_PTR(-ENOMEM). El código de limpieza del controlador de errores en scsi_host_dev_release() llamará a kthread_stop() si shost->ehandler != NULL, que siempre será el caso ya sea que kthread se genere exitosamente o no. En el caso de que no se genere, esto tiene el desagradable efecto secundario de intentar eliminar la referencia a un puntero no válido cuando se llama a kthread_stop(). El siguiente símbolo proporciona un ejemplo de este comportamiento en la naturaleza: scsi host11: el hilo del controlador de errores no pudo generarse, error = -4 El kernel intentó leer la página del usuario (10c): ¿intento de explotación? (uid: 0) ERROR: Desreferencia del puntero NULL del kernel al leer en 0x0000010c Dirección de instrucción errónea: 0xc00000000818e9a8 Ups: Acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 Módulos NUMA pSeries vinculados en: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region hash dm_log dm_mod fuse overlay squashfs loop CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1 NIP: c00000000818e9a8 LR: 9846e8 CTR: 0000000000007ee8 REGS: c000000037d12ea0 TRAMPA : 0300 No contaminado (5.13.0-rc7) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28228228 XER: 20040001 CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0 GPR00: c0000000089846e8 c000000037d13140 000009cc1100 ffffffffffffffffc GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000 GPR08: 0000000000000000 c000000037 dc0000 0000000000000001 00000000fffff7ff GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0 GPR16: 001740 c0080000190d0000 c0080000190d1740 c000000009129288 GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898 GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 000000 0000000000 GPR28: c000000046b28280 0000000000000000 000000000000010c ffffffffffffffffc NIP [c00000000818e9a8] kthread_stop+0x38/0x230 LR [c0000000089 846e8] scsi_host_dev_release+0x98/0x160 Seguimiento de llamadas: [c000000033bb2c48] 0xc000000033bb2c48 (no confiable) [c0000000089846e8] scsi_host_dev_release+0x98 /0x160 [c00000000891e960] device_release+0x60/0x100 [c0000000087e55c4] kobject_release+0x84/0x210 [c00000000891ec78] put_device+0x28/0x40 [c000000008984ea4] host_alloc+0x314/0x430 [c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi] [c000000008110104] vio_bus_probe+ 0xa4/0x4b0 [c00000000892a860] very_probe+0x140/0x680 [c00000000892aefc] driver_probe_device+0x15c/0x200 [c00000000892b63c] device_driver_attach+0xcc/0xe0 [c0000000 0892b740] __driver_attach+0xf0/0x200 [c000000008926f28] bus_for_each_dev+0xa8/0x130 [c000000008929ce4] driver_attach+0x34/ 0x50 [c000000008928fc0] bus_add_driver+0x1b0/0x300 [c00000000892c798] driver_register+0x98/0x1a0 [c00000000810eb60] __vio_register_driver+0x80/0xe0 [c0080000190 b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi] [c0000000080121d0] do_one_initcall+0x60/0x2d0 [c000000008261abc] do_init_module+0x7c /0x320 [c000000008265700] load_module+0x2350/0x25b0 [c000000008265cb4] __do_sys_finit_module+0xd4/0x160 [c000000008031110] system_call_exception+0x150/0x2d0 [c00 000000800d35c] system_call_common+0xec/0x278 Se soluciona esto al anular shost->ehandler cuando el kthread no se genera.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: fbmem: No elimina el modo que aún está en uso. La ejecución de fb_delete_videomode() no se basa en el resultado del fbcon_mode_deleted() anterior. Como resultado, el modo se elimina directamente, independientemente de si todavía está en uso, lo que puede causar UAF. ==================================================== ================ BUG: KASAN: use-after-free en fb_mode_is_equal+0x36e/0x5e0 \ drivers/video/fbdev/core/modedb.c:924 Lectura de tamaño 4 en addr ffff88807e0ddb1c por tarea syz-executor.0/18962 CPU: 2 PID: 18962 Comm: syz-executor.0 No contaminado 5.10.45-rc1+ #3 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS .. Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x137/0x1be lib/dump_stack.c:118 print_address_description+0x6c/0x640 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c: 545 [en línea] kasan_report+0x13d/0x1e0 mm/kasan/report.c:562 fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924 fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon .c:2746 fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [en línea ] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Liberado por tarea 18960: kasan_save_stack mm/kasan/common.c:48 [en línea] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0x108/0x140 mm/kasan/ common.c:422 slab_free_hook mm/slub.c:1541 [en línea] slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574 slab_free mm/slub.c:3139 [en línea] kfree+0xca/0x3d0 mm/slub.c: 4121 fb_delete_videomode+0x56a/0x820 controladores/video/fbdev/core/modedb.c:1104 fb_set_var+0x1f3/0xdb0 controladores/video/fbdev/core/fbmem.c:978 do_fb_ioctl+0x4d9/0x6e0 controladores/video/fbdev/core/ fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [en línea] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/ common.c:46 entrada_SYSCALL_64_after_hwframe+0x44/0xa9

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: v4l2-core: borrar explícitamente los datos de entrada de ioctl. Como se ve en un informe de error reciente de syzbot, los errores en la implementación de compat ioctl pueden llevar a que los datos de la pila del kernel no inicializados se utilicen como entrada para controladores de ioctl del conductor. El error informado ya está solucionado, pero es posible que otros errores relacionados sigan presentes o se agreguen en el futuro. Como los controladores ya necesitan verificar la entrada del usuario, el posible impacto es bastante bajo, pero aún así podría causar una fuga de información. Para estar seguro, borre siempre todo el búfer ioctl antes de llamar a las funciones del controlador de conversión destinadas a inicializarlos.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: KVM: mmio: Arreglar use-after-free Leer en kvm_vm_ioctl_unregister_coalesced_mmio BUG: KASAN: use-after-free en kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../. ./../virt/kvm/coalesced_mmio.c:183 Lectura de tamaño 8 en la dirección ffff0000c03a2500 por tarea syz-executor083/4269 CPU: 5 PID: 4269 Comm: syz-executor083 Not tainted 5.10.0 #7 Nombre de hardware: linux ,dummy-virt (DT) Seguimiento de llamadas: dump_backtrace+0x0/0x2d0 arch/arm64/kernel/stacktrace.c:132 show_stack+0x28/0x34 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x110/0x164 lib/dump_stack.c:118 print_address_description+0x78/0x5c8 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [en línea] kasan_report+0x148/0x1e4 mm/kasan /report.c:562 check_memory_region_inline mm/kasan/generic.c:183 [en línea] __asan_load8+0xb4/0xbc mm/kasan/generic.c:252 kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../ ../virt/kvm/coalesced_mmio.c:183 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755 vfs_ioctl fs/ioctl.c:48 [ en línea] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl fs/ioctl.c:739 [en línea] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [en línea ] invoke_syscall arch/arm64/kernel/syscall.c:48 [en línea] el0_svc_common arch/arm64/kernel/syscall.c:158 [en línea] do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220 el0_svc+0x1c /0x28 arch/arm64/kernel/entry-common.c:367 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670 Asignado por tarea 4269: stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121 kasan_save_stack mm/kasan/common.c:48 [en línea] kasan_set_track mm/kasan/common.c:56 [en línea] __kasan_kmalloc+0xdc/0x120 mm/kasan /common.c:461 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:475 kmem_cache_alloc_trace include/linux/slab.h:450 [en línea] kmalloc include/linux/slab.h:552 [en línea] kzalloc include/linux /slab.h:664 [en línea] kvm_vm_ioctl_register_coalesced_mmio+0x78/0x1cc arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:146 kvm_vm_ioctl+0x7e8/0x14c4 arch/arm64/kvm/. ./../../virt/kvm/kvm_main.c:3746 vfs_ioctl fs/ioctl.c:48 [en línea] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl fs/ioctl.c:739 [en línea] __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:36 [en línea] invoke_syscall arch/arm64/kernel/syscall.c:48 [en línea] el0_svc_common arch/arm64/kernel/syscall .c:158 [en línea] do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367 el0_sync_handler+0x98/0x170 arch/arm64/ kernel/entry-common.c:383 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670 Liberado por la tarea 4269: stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121 kasan_save_stack mm/kasan/common.c :48 [en línea] kasan_set_track+0x38/0x6c mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:355 __kasan_slab_free+0x124/0x150 mm/kasan/common.c:422 kasan_slab_free+0x10 /0x1c mm/kasan/common.c:431 slab_free_hook mm/slub.c:1544 [en línea] slab_free_freelist_hook mm/slub.c:1577 [en línea] slab_free mm/slub.c:3142 [en línea] kfree+0x104/0x38c mm /slub.c:4124 coalesced_mmio_destructor+0x94/0xa4 arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:102 kvm_iodevice_destructor include/kvm/iodev.h:61 [en línea] kvm_io_bus_unregister_dev+ 0x248/0x280 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:4374 kvm_vm_ioctl_unregister_coalesced_mmio+0x158/0x1ec arch/arm64/kvm/../../../virt/kvm /coalesced_mmio.c:186 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755 vfs_ioctl fs/ioctl.c:48 [en línea] __do_sys_ioctl fs/ioctl .c:753 [en línea] __se_sys_ioctl fs/ioctl.c:739 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige posible UAF al remontar el sistema de archivos protegido por r/oa mmp. Después del commit 618f003199c6 ("ext4: corrige la pérdida de memoria en ext4_fill_super"), después de que se vuelve a montar el sistema de archivos solo que hay una ejecución donde el hilo kmmpd puede salir, causando que sbi->s_mmp_tsk apunte a la memoria liberada, con la que la llamada a ext4_stop_mmpd() puede tropezar. Solucione este problema permitiendo que kmmpd() salga solo cuando se detiene a través de ext4_stop_mmpd(). Enlace de informe de error: <20210629143603.2166962-1-yebin10@huawei.com>

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm btree remove: asigna new_root solo cuando la eliminación se realiza correctamente. remove_raw() en dm_btree_remove() puede fallar debido a un error de lectura de E/S (por ejemplo, la lectura del contenido del bloque de origen falla durante el sombreado), y el valor de shadow_spine::root no está inicializado, pero el valor no inicializado aún se asigna a new_root al final de dm_btree_remove(). Para dm-thin, el valor de pmd->details_root o pmd->root se convertirá en un valor no inicializado, por lo que si intenta leer el árbol de detalles_info nuevamente, puede ocurrir que la memoria esté fuera de los límites, como se muestra a continuación: falla de protección general, probablemente para no usuarios. -dirección canónica 0x3fdcb14c8d7520 CPU: 4 PID: 515 Comm: dmsetup No contaminado 5.13.0-rc6 Nombre de hardware: QEMU PC estándar RIP: 0010:metadata_ll_load_ie+0x14/0x30 Seguimiento de llamadas: sm_metadata_count_is_more_than_one+0xb9/0xe0 m_shadow_block+0x52/0x1c0 sombra_paso+ 0x59/0xf0 remove_raw+0xb2/0x170 dm_btree_remove+0xf4/0x1c0 dm_pool_delete_thin_device+0xc3/0x140 pool_message+0x218/0x2b0 target_message+0x251/0x290 ctl_ioctl+0x1c4/0x4d0 _ctl_ioctl+0xe/0x20 __x64_sys_ioctl+0x7b/0xb0 do_syscall_64+0x40/0xb0 entrada_SYSCALL_64_after_hwframe+ 0x44/0xae Se soluciona asignando new_root únicamente cuando la eliminación se realiza correctamente

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: jfs: corrige GPF en diFree. Evite pasar el inodo con JFS_SBI(inode->i_sb)->ipimap == NULL a diFree()[1]. Aparecerá GFP: struct inode *ipimap = JFS_SBI(ip->i_sb)->ipimap; estructura inomap *imap = JFS_IP(ipimap)->i_imap; JFS_IP() devolverá un puntero no válido cuando ipimap == NULL Seguimiento de llamadas: diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1] jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154 evict+0x2ed/ 0x750 fs/inode.c:578 iput_final fs/inode.c:1654 [en línea] iput.part.0+0x3fe/0x820 fs/inode.c:1680 iput+0x58/0x70 fs/inode.c:1670

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/bpf: Corrección de la detección de instrucciones atómicas BPF. La confirmación 91c960b0056672 ("bpf: Renombrar BPF_XADD y prepararse para codificar otros átomos en .imm") convirtió BPF_XADD a BPF_ATOMIC y agregó una forma de distinguir instrucciones basadas en el campo inmediato. Las implementaciones JIT existentes se actualizaron para verificar el campo inmediato y rechazar programas que utilicen algo más que BPF_ADD (como BPF_FETCH) en el campo inmediato. Sin embargo, la verificación agregada a powerpc64 JIT no analizó la instrucción BPF correcta. Debido a esto, dichos programas serían aceptados y sometidos a JIT incorrectamente, lo que provocaría bloqueos suaves, como se ve con la prueba de límites atómicos. Solucione este problema observando el valor inmediato correcto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arch_topology: Evite el use after free para scale_freq_data. Actualmente, topology_scale_freq_tick() (que se llama desde Scheduler_tick()) puede terminar usando un puntero a "struct scale_freq_data", que anteriormente era borrado por topology_clear_scale_freq_source(), ya que no existe ninguna protección aquí. Sin embargo, los usuarios de topology_clear_scale_freq_source() necesitan una garantía de que el scale_freq_data previamente borrado ya no se utiliza, para que puedan liberar los recursos relacionados. Dado que topology_scale_freq_tick() se llama desde el tick del programador, no queremos agregar bloqueo allí. Utilice en su lugar el mecanismo de actualización de RCU (que ya se utiliza en la ruta de actualización de utilización del programador) para garantizar actualizaciones sin ejecucións aquí. sincronizar_rcu() se asegura de que todas las secciones críticas de RCU que comenzaron antes de ser llamada terminen antes de que regrese. Y así, las personas que llaman a topology_clear_scale_freq_source() ya no necesitan preocuparse de que se llame a su devolución de llamada.