Vulnerabilidades

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

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/dp: Se corrigió la regresión de división por cero en DP MST desconectar con nouveau Se corrigió una regresión al usar nouveau y desconectar un concentrador MST StarTech MSTDP122DP DisplayPort 1.2 (la misma regresión no aparecen cuando se utiliza un concentrador Cable Matters DisplayPort 1.4 MST). Seguimiento: error de división: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744 Nombre de hardware: Razer Blade/DANA_MB, BIOS 01.01 31/08/2018 RIP: 0010: drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] Código: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 y siguientes <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31 RSP: 0018:ffffb2c5c211fa30 EFLAGS: 00010206 RAX: ffffffffffffffff RBX: 000000000 RCX: 0000000000f59b00 RDX: 0000000000000000 RSI: 0000000000000000 RDI : 0000000000000000 RBP: ffffb2c5c211fa48 R08: 0000000000000001 R09: 0000000000000020 R10: 00000000000000004 R11: 0000000000000000 R12: 0000000000023b4a R13: ffff91d37d165800 R14: ffff91d36fac6d80 R15: ffff91d34a764010 FS: 00007f4a1ca3fa80(0000) GS:ffff91d6edbc0000(0000) 00000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559491d49000 CR3: 000000011d180002 CR4: 00000000003706f0 Seguimiento de llamadas: ? show_regs+0x6d/0x80? morir+0x37/0xa0? do_trap+0xd4/0xf0? do_error_trap+0x71/0xb0? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? exc_divide_error+0x3a/0x70? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? asm_exc_divide_error+0x1b/0x20? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper] nv50_msto_atomic_check+0xda/0x120 [nuevo] drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper] drm_atomic_helper_check+0x19/0xa0 [drm_km s_helper] nv50_disp_atomic_check+0x13f/0x2f0 [nuevo] drm_atomic_check_only+0x668/0xb20 [drm]? drm_connector_list_iter_next+0x86/0xc0 [drm] drm_atomic_commit+0x58/0xd0 [drm] ? __pfx___drm_printfn_info+0x10/0x10 [drm] drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] drm_connector_property_set_ioctl+0x3b/0x60 [drm] drm_ioctl_kernel+0xb9/0x120 [drm] drm_ioctl+0x2d0/0x550 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] nouveau_drm_ioctl+0x61/0xc0 [nuevo] __x64_sys_ioctl+0xa0/0xf0 do_syscall_64+0x76/0x140 ? do_syscall_64+0x85/0x140? do_syscall_64+0x85/0x140 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f4a1cd1a94f Código: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 RSP: 002b:00007ffd2f1df520 EFLAGS: 0246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd2f1df5b0 RCX: 00007f4a1cd1a94f RDX: 00007ffd2f1df5b0 RSI: 00000000c01064ab RDI: 000000000000000f RBP: 00000000c01064ab R08: 000056347932deb8 R09: 00056347a7d99c0 R10: 0000000000000000 R11: 0000000000000246 R12: 000056347938a220 R13: 0000000000000000f R14: 0000563479d9f3f0 0000000000000000 Módulos vinculados en: rfcomm xt_conntrack nft_chain_nat xt_masquerade nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo Xad_addrtype nft_compat nf_tables nfnetlink br_netfilter puente stp llc ccm cmac alkh_ overkh_ overkh_ overkh_ overkh_ overgh_ upny _alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda SOC_ACPP SOCPI SND_SOC_CORE SND_COMPRESS SND_SOF_INTEL_INTEL_HDA_MLINK SND_HDA_EXT_CORE IWLMVM Intel_raPl_MMSR Intel_raPl_Common Intel_tccc_Cooling x86_pkg_temp_Thermal Intel_PowerClAMCCLAMCCLAMCCLAMCO11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111. a_codec_hdmi kvm snd_hda_ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: qcom: at803x: corrige el pánico del kernel con at8031_probe Al reelaborar y dividir el controlador at803x, en la función de división de los PHY de at803x se agregó un error de desreferencia NULL donde se hace referencia a priv antes de que realmente se asigne y luego se intenta escribir para las variables is_1000basex e is_fiber en el caso de at8031, escribiendo en la dirección incorrecta. Solucione este problema configurando correctamente la variable local priv solo después de llamar a at803x_probe y realmente asignar priv en la estructura phydev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/dmem: maneja el error de asignación de kcalloc() El kcalloc() en nouveau_dmem_evict_chunk() devolverá nulo si la memoria física se ha agotado. Como resultado, si eliminamos la referencia a src_pfns, dst_pfns o dma_addrs, se producirán errores de desreferenciación del puntero nulo. Además, la GPU está desapareciendo. Si kcalloc() falla, no podremos desalojar todas las páginas que asignan un fragmento. Entonces este parche agrega un indicador __GFP_NOFAIL en kcalloc(). Finalmente, como no es necesario tener memoria físicamente contigua, este parche cambia kcalloc() a kvcalloc() para evitar asignaciones fallidas.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() Si no tenemos VBT, o el VBT no declaró el codificador en cuestión, no tendremos los 'devdata' para el codificador. En lugar de huir, simplemente sal de la cárcel antes de tiempo. No podremos saber si el puerto es DP++ o no, pero que así sea. (cereza escogida del compromiso 26410896206342c8a80d2b027923e9ee7d33b733)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: corrige el punto muerto en usb_deauthorize_interface() Entre las rutinas de devolución de llamada de archivos de atributos en drivers/usb/core/sysfs.c, la función interface_authorized_store() es la única que adquiere un bloqueo de dispositivo en un dispositivo antecesor: llama a usb_deauthorize_interface(), que bloquea el dispositivo USB principal de la interfaz. Esto conducirá a un punto muerto si otro proceso ya posee ese bloqueo e intenta eliminar la interfaz, ya sea mediante un cambio de configuración o porque el dispositivo se ha desconectado. Como parte del procedimiento de eliminación, device_del() espera a que se completen todas las devoluciones de llamadas de atributos sysfs en curso. Pero usb_deauthorize_interface() no se puede completar hasta que se haya liberado el bloqueo del dispositivo, y el bloqueo no se liberará hasta que haya finalizado la eliminación. El mecanismo proporcionado por sysfs para evitar este tipo de punto muerto es utilizar la función sysfs_break_active_protection(), que le dice a sysfs que no espere la devolución de llamada del atributo. Reportado y probado por: Yue Sun Reportado por: xingwei lee

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: validar el tamaño del búfer de solicitud en smb2_allocate_rsp_buf() El búfer de respuesta debe asignarse en smb2_allocate_rsp_buf antes de validar la solicitud. Pero los campos en el payload y el encabezado smb2 se usan en smb2_allocate_rsp_buf(). Este parche agrega una validación simple del tamaño del búfer para evitar posibles límites en el búfer de solicitud.