Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Revisar la rutina lpfc_prep_embed_io con usos de macro endian adecuados. En arquitecturas big endian, es posible ejecutar una desreferencia de puntero de memoria fuera de los límites cuando los objetivos FCP están divididos en zonas. En lpfc_prep_embed_io, memcpy(ptr, fcp_cmnd, sgl->sge_len) hace referencia a un valor sgl->sge_len con formato little endian. Por lo tanto, memcpy puede provocar que los sistemas big endian colapsen. Redefina *sgl ptr como una estructura sli4_sge_le para dejar claro que nos referimos a una estructura de datos con formato little endian. Y actualice la rutina con usos adecuados de la macro le32_to_cpu.

Metform Elementor Contact Form Builder para WordPress es vulnerable a la carga arbitraria de archivos debido a una validación insuficiente del tipo de archivo en versiones hasta la 3.2.4 incluida. Esto permite a los visitantes no autenticados realizar un ataque de "doble extensión" y cargar archivos que contienen una extensión maliciosa pero que terminan con una extensión benigna, lo que puede hacer posible la ejecución remota de código en algunas configuraciones.

Una vulnerabilidad fue encontrada en LimeSurvey 6.3.0-231016 y clasificada como problemática. Una función desconocida del archivo /index.php del componente File Upload es afectada por esta vulnerabilidad. La manipulación del tamaño del argumento conduce a la denegación de servicio. El ataque puede lanzarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/huge_memory: evite el caché de páginas de tamaño PMD si es necesario. xarray no puede admitir un tamaño de caché de páginas arbitrario. el tamaño de caché de página más grande y admitido se define como MAX_PAGECACHE_ORDER mediante el commit 099d90642a71 ("mm/filemap: hacer que MAX_PAGECACHE_ORDER sea aceptable para xarray"). Sin embargo, es posible tener una caché de página de 512 MB en la ruta de colapso de la enorme memoria en un sistema ARM64 cuyo tamaño de página base es de 64 KB. La caché de página de 512 MB supera la limitación y aparece una advertencia cuando la entrada de xarray se divide como se muestra en el siguiente ejemplo. [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char **argv) { const char *filename = TEST_XFS_FILENAME; intfd = 0; vacío *buf = (vacío *)-1, *p; int pgsize = getpagesize(); int ret = 0; if (pgsize != 0x10000) { fprintf(stdout, "¡Se requiere un sistema con un tamaño de página base de 64 KB!\n"); devolver -EPERM; } system("echo 0 > /sys/devices/virtual/bdi/253:0/read_ahead_kb"); sistema("echo 1 > /proc/sys/vm/drop_caches"); /* Abrir el archivo xfs */ fd = open(nombre de archivo, O_RDONLY); afirmar(fd > 0); /* Crear VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0); afirmar(buf != (void *)-1); fprintf(stdout, "búfer asignado en 0x%p\n", buf); /* Completar VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE); afirmar(ret == 0); ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ); afirmar(ret == 0); /* Contraer VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); afirmar(ret == 0); ret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE); if (ret) { fprintf(stdout, "Error %d en madvise(MADV_COLLAPSE)\n", errno); salir; } /* Dividir entrada de matriz x. Se necesita permiso de escritura */ munmap(buf, TEST_MEM_SIZE); buf = (nulo *)-1; cerrar(fd); fd = open(nombre de archivo, O_RDWR); afirmar(fd > 0); fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - tamaño de página, tamaño de página); salida: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); si (fd > 0) cerrar(fd); volver atrás; } [root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test [root@dhcp-10-26-1-207 ~]# /tmp/test -- ----------[ cortar aquí ]------------ ADVERTENCIA: CPU: 25 PID: 7560 en lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Módulos vinculados en : nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ _set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse \ xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 virtio_net \ sha1_ce net_failover virtio_blk virtio_console failover dimlib virtio_mmio CPU: 25 PID: 7560 Comm : prueba Kdump: cargado No contaminado 6.10.0-rc7-gavin+ #9 Nombre del hardware: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 24/05/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO + DIT -SSBS BTYPE=--) pc: xas_split_alloc+0xf8/0x128 lr: split_huge_page_to_list_to_order+0x1c4/0x780 sp: ffff8000ac32f660 x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: 000ac32f6c0 x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21 : 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000 x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: ffffffffffffffc0 x10: 0000000000000040 x9: 08e692c x8: 0000000000000003 x7: 0000000000000000 x6: ffff0000e0969eb8 x5: ffffd5f37289e378 x4: 0000000000000000 x3: 0000000000000c40 x2: 000000000000000d x1: 000000000000000c x0: 0000000000000000 Rastreo de llamadas: xas_split_alloc+0xf8/0x128 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige un posible punto muerto en __exfat_get_dentry_set Al acceder a un archivo con más entradas que ES_MAX_ENTRY_NUM, la matriz bh se asigna en __exfat_get_entry_set. El problema es que el bh-array está asignado con GFP_KERNEL. No tiene sentido. En los siguientes casos, puede ocurrir un punto muerto para sbi->s_lock entre los dos procesos. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... desalojar exfat_evict_inode lock(&sbi->s_lock) para arreglar esto, asignemos bh-array con GFP_NOFS.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: buzón: mtk-cmdq: mover devm_mbox_controller_register() después de devm_pm_runtime_enable() Cuando mtk-cmdq se desvincula, aparece un mensaje WARN_ON con la condición pm_runtime_get_sync() < 0. De acuerdo con el seguimiento de llamadas a continuación: cmdq_mbox_shutdown mbox_free_channel mbox_controller_unregister __devm_mbox_controller_unregister ... Se puede deducir que la causa raíz es llamar a pm_runtime_get_sync() después de llamar a pm_runtime_disable() como se observa a continuación: 1. El controlador CMDQ usa devm_mbox_controller_register() en cmdq_probe() para vincular el cmdq al mbox_controller, por lo que devm_mbox_controller_unregister() cancelará automáticamente el registro del dispositivo vinculado al controlador del buzón cuando se elimine el recurso administrado por el dispositivo. Eso significa que devm_mbox_controller_unregister() y cmdq_mbox_shoutdown() serán llamados después de cmdq_remove(). 2. El controlador CMDQ también usa devm_pm_runtime_enable() en cmdq_probe() después de devm_mbox_controller_register(), por lo que se llamará a devm_pm_runtime_disable() después de cmdq_remove(), pero antes de devm_mbox_controller_unregister(). Para solucionar este problema, cmdq_probe() necesita mover devm_mbox_controller_register() después de devm_pm_runtime_enable() para que se llame a devm_pm_runtime_disable() después de devm_mbox_controller_unregister().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/gma500: corrige la desreferencia del puntero nulo en cdv_intel_lvds_get_modes En cdv_intel_lvds_get_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hfs: corrección para inicializar campos de hfs_inode_info después de hfs_alloc_inode() Syzbot informa un problema de acceso a valores no inicializados como se muestra a continuación: loop0: cambio de capacidad detectado de 0 a 64 ======== ============================================== ERROR: KMSAN: uninit -valor en hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [en línea] lookup_fast+0x89e/0x8e0 nombrei .c:1649 walk_component fs/namei.c:2001 [en línea] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c: 2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [en línea] do_mount fs/namespace.c:3689 [en línea] __do_sys_mount fs/namespace.c:3898 [en línea] __se_sys_mount+ 0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common. c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b ERROR: KMSAN: valor uninit en hfs_ext_read_extent fs/hfs/extent.c:196 [en línea] ERROR: KMSAN: valor uninit en hfs_get_block+0x92d/0x1620 fs/hfs/extent.c: 366 hfs_ext_read_extent fs/hfs/extent.c:196 [en línea] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 s/inodo .c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [en línea] read_cache_page+0xfb/0x2f0 mm/filemap.c: 3604 read_mapping_page include/linux/pagemap.h:755 [en línea] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/ hfs /super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 Legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs /super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [en línea] __do_sys_mount fs/namespace.c:3697 [ en línea] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [en línea] 2/0x100 arco/x86/ Entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 Entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit se creó en: __alloc_pages +0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [en línea] alloc_pages_node include/linux/gfp.h:261 [en línea] alloc_slab_page mm/slub.c:2190 [en línea] allocate_slab mm /slub.c:2354 [en línea] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [en línea] __slab_alloc_node mm/slub.c :3678 [en línea] slab_alloc_node mm/slub.c:3850 [en línea] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [en línea] hfs_alloc_inode+0x5a/0xc0 fs/hfs/ super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [en línea] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode .c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:416 4 [en línea] __se_sys_mkdirat fs/namei.c:4162 [en línea] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86 / Entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b No pudo inicializar los campos .tz_segundoswest, .cached_start y .cached_blocks en la estructura hfs_inode_info después de hfs_alloc_inode(), solucionelo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sysctl: inicializar siempre i_uid/i_gid Inicializar siempre i_uid/i_gid dentro del núcleo sysfs para que set_ownership() pueda omitir su configuración de forma segura. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: corrija los valores predeterminados de i_uid/i_gid en los inodos /proc/sys.") agregó valores predeterminados para i_uid/i_gid cuando no se implementó set_ownership(). También omitió ajustar net_ctl_set_ownership() para usar los mismos valores predeterminados en caso de que fallara el cálculo de un valor mejor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: venus: arreglar el use after free en vdec_close Parece haber un posible use after free con vdec_close(). El firmware agregará trabajo de liberación de búfer a la cola de trabajos a través de devoluciones de llamada HFI como parte normal de la decodificación. Cerrar aleatoriamente el dispositivo decodificador desde el espacio de usuario durante la decodificación normal puede generar una lectura después de la liberación por instante. Solucionarlo cancelando el trabajo en vdec_close.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el use after free el mapa de extensión al agregar páginas a una biografía comprimida En add_ra_bio_pages() estamos accediendo al mapa de extensión para calcular 'add_size' después de que eliminamos nuestra referencia en el mapa de extensión, lo que resulta en un use-after-free. Solucione este problema calculando 'add_size' antes de eliminar nuestra referencia del mapa de extensión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mglru: corrige div-by-zero en vmpression_calc_level() evict_folios() utiliza una segunda pasada para recuperar las publicaciones que han pasado por la reescritura de páginas y quedan limpias antes de finalizar el primer pase, ya que folio_rotate_reclaimable() no puede manejar esos folios debido al aislamiento. El segundo paso intenta evitar un posible doble conteo deduciendo scan_control->nr_scanned. Sin embargo, esto puede resultar en un desbordamiento insuficiente de nr_scanned, bajo una condición en la que Shrink_folio_list() no incrementa nr_scanned, es decir, cuando falla folio_trylock(). El desbordamiento insuficiente puede causar que el divisor, es decir, escala=escaneado+reclamado en vmpression_calc_level(), se convierta en cero, lo que resulta en el siguiente bloqueo: [excepción RIP: vmpression_work_fn+101] Process_one_work en ffffffffa3313f2b Dado que scan_control->nr_scanned no tiene una semántica establecida, la posible doble contabilización tiene riesgos mínimos. Por lo tanto, solucione el problema no deduciendo scan_control->nr_scanned en evict_folios().