Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: corrige slab-out-of-bounds en smb_strndup_from_utf16() Si ->NameOffset de smb2_create_req es menor que el desplazamiento del búfer de smb2_create_req, puede ocurrir una lectura de slab-out-of-bounds de smb2_open. Este parche establece el valor mínimo del desplazamiento del nombre en el desplazamiento del búfer para validar la longitud del nombre de smb2_create_req().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wireguard: netlink: verifique si hay pares pendientes a través de is_dead en lugar de una lista vacía. Si todos los pares se eliminan a través de wg_peer_remove_all(), en lugar de configurar peer_list como vacío, el par se agrega a una lista temporal. lista con un encabezado en la pila de wg_peer_remove_all(). Si se reanuda un volcado de netlink y el par seleccionado es uno que se eliminó mediante wg_peer_remove_all(), iterará desde ese par y luego intentará volcar los pares liberados. Para solucionar este problema, marque peer->is_dead, que se creó explícitamente para este propósito. También suba la aserción de bloqueo de dispositivo_update_lock, ya que la lectura is_dead depende de eso. Se puede reproducir mediante un pequeño script como: echo "Configuración de configuración..." ip link add dev wg0 tipo wireguard wg setconf wg0 /big-config (mientras sea verdadero; haga echo "Mostrando configuración..." wg showconf wg0 > / dev/null done) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resultando en: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x182a/0x1b20 Lectura de tamaño 8 en la dirección ffff88811956ec70 mediante la tarea wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Seguimiento de llamadas: dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c /0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el error al detectar daños en DAT en btree y asignaciones directas Serie de parches "nilfs2: corrige el error del kernel en submit_bh_wbc()". Esto resuelve un ERROR del kernel informado por syzbot. Dado que hay dos fallas involucradas, hice un parche para cada uno por separado. El primer parche por sí solo resuelve el error reportado por syzbot, pero creo que ambas correcciones deberían enviarse a estable, así que las etiqueté como tales. Este parche (de 2): Syzbot ha informado de un error en el kernel en submit_bh_wbc() al escribir datos de archivos en un sistema de archivos nilfs2 cuyos metadatos están dañados. Hay dos errores involucrados en este tema. El primer defecto es que cuando nilfs_get_block() localiza un bloque de datos usando btree o mapeo directo, si la rutina de traducción de direcciones de disco nilfs_dat_translate() falla con el código interno -ENOENT debido a la corrupción de los metadatos DAT, se puede devolver a nilfs_get_block(). Esto hace que nilfs_get_block() identifique erróneamente un bloque existente como inexistente, lo que provoca que tanto la búsqueda como la inserción del bloque de datos fallen de manera inconsistente. El segundo defecto es que nilfs_get_block() devuelve un estado exitoso en este estado inconsistente. Esto hace que la persona que llama __block_write_begin_int() u otros soliciten una lectura aunque el búfer no esté asignado, lo que resulta en una verificación BUG_ON para el indicador BH_Mapped en submit_bh_wbc() que falla. Esto soluciona el primer problema cambiando el valor de retorno al código -EINVAL cuando falla una conversión usando DAT con el código -ENOENT, evitando la condición conflictiva que conduce al error del kernel descrito anteriormente. Aquí, el código -EINVAL indica que se detectó corrupción de metadatos durante la búsqueda del bloque, lo que se manejará adecuadamente como un error del sistema de archivos y se convertirá a -EIO al pasar a través de la capa bmap nilfs2.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: previene el error del kernel en submit_bh_wbc(). Se corrige un error por el cual nilfs_get_block() devuelve un estado exitoso cuando la búsqueda y la inserción del bloque especificado fallan de manera inconsistente. Si este comportamiento inconsistente no se debe a un error solucionado previamente, entonces se está produciendo una ejecución inesperada, por lo que se devuelve un error temporal -EAGAIN. Esto evita que llamadores como __block_write_begin_int() soliciten una lectura en un búfer que no está asignado, lo que provocaría que falle la verificación BUG_ON del indicador BH_Mapped en submit_bh_wbc().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: iaa - Corrige el caso nr_cpus < nr_iaa Si nr_cpus < nr_iaa, el cpus_per_iaa calculado será 0, lo que provoca una división por 0 en rebalance_wq_table(). Asegúrese de que cpus_per_iaa sea 1 en ese caso, y también en el caso de nr_iaa == 0, aunque cpus_per_iaa nunca se use si nr_iaa == 0, para paranoia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes/x86: use copy_from_kernel_nofault() para leer desde una dirección no segura Lea desde una dirección no segura con copy_from_kernel_nofault() en arch_adjust_kprobe_addr() porque esta función se usa antes de verificar que la dirección esté en texto O no. El bot Syzcaller encontró un error e informó el caso si el usuario especifica un área de datos inaccesible, arch_adjust_kprobe_addr() provocará un pánico en el kernel. [ mingo: Aclaró el comentario. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: 9359/1: descarga: verifique si la publicación está reservada para direcciones sin asignación. Desde el commit a4d5613c4dc6 ("arm: extienda pfn_valid para tener en cuenta la alineación del mapa de memoria liberada") cambia la semántica de pfn_valid() para verificar la presencia del mapa de memoria para un PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] el diseño de uio es? 0xc0900000, 0x100000 el seguimiento del fallo es como: No se puede manejar la solicitud de paginación del kernel en la dirección virtual bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Contaminado: GO 5.10.0 #1 Nombre del hardware: La PC del sistema basado en DT genérico está en b15_flush_kern_dcache_area+0x24/0x3c LR está en __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) de (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) de (set_pte_at+0x2 8/0x54) (set_pte_at) desde (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) desde (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) desde (__mmap_region+0x264/0x5f4) (__mmap_region) desde (__do_mmap_mm+0x3ec/0x440) milímetros) de (do_mmap+0x50/0x58) (do_mmap) de (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) de (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) de (ret_fast_syscall+0x0/0x5c) Código: e0801001 423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Pánico del kernel - no se sincroniza: excepción fatal. Así que verifique si PG_reserved estaba configurado para resolver este problema. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: agregue una verificación dc_state NULL en dc_state_release [Cómo] Verifique si el estado es NULL antes de liberarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu/pm: corrige la desreferencia del puntero NULL cuando se obtiene el límite de energía. Debido a que la inicialización de powerplay_table se omite en el caso sriov, verificamos y configuramos el valor OD inferior y superior predeterminado si powerplay_table es NULL.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs:zoned: corrige use-after-free en do_zone_finish() Shinichiro informó el siguiente use-after-free desencadenado por la operación de reemplazo de dispositivo en fstests btrfs/070. Información BTRFS (dispositivo nullb1): limpieza: finalizado en el dispositivo 1 con estado: 0 ================================== ================================= ERROR: KASAN: uso de losa después de liberarlo en do_zone_finish+0x91a/0xb90 [btrfs] Lectura del tamaño 8 en la dirección ffff8881543c8060 mediante la tarea btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Contaminado: GW 6.8.0-rc5-kts #1 Nombre del hardware: Supermicro Super Server/X11SPi-TF , BIOS 3.3 21/02/2020 Seguimiento de llamadas: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs]? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] clean_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Asignado por tarea 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0x b3/0x4e0 [btrfs] lista_dispositivo_add.constprop.0+0x993/ 0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entrada_SYSCALL_6 4_after_hwframe+0x6e/0x76 Liberado por la tarea 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 veneno_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs_dev_replace_finishing+0xd 7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [ btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 La dirección con errores pertenece al objeto en ffff8881543c8000 que pertenece al caché kmalloc-1k de tamaño 1024 Se encuentra la dirección con errores 96 bytes dentro de los 1024 bytes liberados región [ffff8881543c8000, ffff8881543c8400) La dirección del error pertenece a la página física: página:00000000fe2c1285 refcount:1 mapcount:0 mapeo:00000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 entero_mapcount:0 nr_pages_mapped:0 pincount:0 banderas: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) tipo de página: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000 0000000000100010 00000001ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección con errores : ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Esta UAF sucede porque estamos acceder a información de zona obsoleta de un btrfs_device ya eliminado en do_zone_finish(). La secuencia de eventos es la siguiente: btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- dispositivos reemplazados btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- dispositivo liberado clean_kthread btrfs_delete_unused_ bgs btrfs_zone_finish do_zone_finish <-- hace referencia al dispositivo liberado. La razón de esto es que estamos usando un ---truncado ---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/i915/vma: Corrección de UAF al destruir contra ejecución de retirada. Las herramientas de depuración de objetos informaban esporádicamente intentos ilegales de liberar un objeto i915 VMA aún activo al estacionar un GT que se creía que estaba inactivo. [161.359441] ODEBUG: objeto activo libre (estado activo 0): ffff88811643b958 tipo de objeto: i915_active sugerencia: __i915_vma_active+0x0/0x50 [i915] [161.360082] ADVERTENCIA: CPU: 5 PID: 276 en lib/debugobjects.c:514 _imprimir_objeto+ 0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 No contaminado 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Nombre de hardware: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 21/04/2022 [161.360322] Cola de trabajo: i915 desordenado __intel_wakeref_put_work [i915] [161.360592] RIP 0010:debug_print_object+0x 80/0xb0... [161.361347] debug_object_free +0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] referencias de versión+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] .363129] __gt_park+0x121/0x230 [i915] [161.363515 ] ____intel_wakeref_put_last+0x1f/0x70 [i915] Se ha rastreado que eso sucede cuando otro subproceso desactiva el VMA dentro del asistente __active_retire(), después de que el contador activo del VMA ya se haya reducido a 0, pero antes de que se desactive la desactivación del objeto del VMA. reportado a la herramienta de depuración de objetos. Podríamos evitar esa ejecución serializando i915_active_fini() con __active_retire() a través de ref->tree_lock, pero eso no impediría que se use VMA, por ejemplo, desde __i915_vma_retire() llamado al final de __active_retire(), después de ese VMA ya ha sido liberado por un i915_vma_destroy() concurrente al regresar de i915_active_fini(). Entonces, deberíamos solucionar el problema a nivel de VMA, no en i915_active. Dado que __i915_vma_parked() se llama desde __gt_park() en la última colocación del wakeref del GT, el problema podría solucionarse manteniendo el wakeref del GT el tiempo suficiente para que __active_retire() se complete antes de que se libere el wakeref y se estacione el GT. Creo que el problema fue introducido por el commit d93939730347 ("drm/i915: Eliminar el recuento de vma") que movió una llamada a i915_active_fini() desde un i915_vma_release() eliminado, llamado en la última colocación del kref de VMA eliminado, a i915_vma_parked() ruta de procesamiento llamada en la última colocación de un wakeref GT. Sin embargo, su visibilidad para la herramienta de depuración de objetos fue suprimida por un error en i915_active que se solucionó dos semanas después con el commit e92eb246feb9 ("drm/i915/active: Reparar la activación del objeto de depuración que falta"). Un VMA asociado con una solicitud no adquiere un wakeref GT por sí solo. En cambio, depende de un wakeref mantenido directamente por el intel_context activo de la solicitud para un GT asociado con su VM, e indirectamente del wakeref del motor de ese intel_context si el motor pertenece al mismo GT que la VM del VMA. Esos wakerefs se liberan de forma asincrónica con la desactivación de VMA. Solucione el problema obteniendo un wakeref para el GT del VMA al activarlo y colocando ese wakeref solo después de que se desactive el VMA. Sin embargo, excluya el GTT global de esa ruta de procesamiento; de lo contrario, la GPU nunca quedará inactiva. Dado que se puede llamar a __i915_vma_retire() desde contextos atómicos, utilice la variante asíncrona de wakeref put. Además, para evitar la dependencia del bloqueo circular, tenga cuidado de adquirir el wakeref antes del mutex de VM cuando ambos sean necesarios. v7: agregue comentarios en línea con justificaciones para: - usar variantes sin seguimiento de intel_gt_pm_get/put() (Nirmoy), - usar la variante asíncrona de _put(), - no obtener el wakeref en caso de un GTT global, - obtener siempre el primer wakeref fuera de vm->mutex. ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: cree la entrada debugfs ttm_resource_manager solo si es necesario. El controlador crea /sys/kernel/debug/dri/0/mob_ttm incluso cuando el ttm_resource_manager correspondiente no está asignado. Esto provoca un bloqueo al intentar leer este archivo. Agregue una marca para crear archivos de depuración mob_ttm, system_mob_ttm y gmr_ttm solo cuando se asigne el ttm_resource_manager correspondiente. crash> bt PID: 3133409 TAREA: ffff8fe4834a5000 CPU: 3 COMANDO: "grep" #0 [ffffb954506b3b20] machine_kexec en ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec en ffffffffb2bb598a #2 ffb954506b3c38] crash_kexec en ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end en ffffffffb2a2a9b1 # 4 [ffffb954506b3c70] no_context en ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore en ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault en ffffffffb2a7f887 #7 54506b3d40] page_fault en ffffffffb360116e [excepción RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb9545 06b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffff CS: 0010 SS : 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show en ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read en ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 00000000000000 03 PBR: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b