Vulnerabilidades

El complemento Colibri Page Builder de WordPress es vulnerable a cross-site scripting almacenado a través del código corto 'colibri_post_title' del complemento en todas las versiones hasta la 1.0.263 incluida debido a una desinfección de entrada y a un escape de salida en atributos proporcionados por el usuario como 'heading_type' insuficientes. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

En OpenHarmony v4.0.0 y versiones anteriores permiten que un atacante local ejecute código arbitrario en aplicaciones preinstaladas mediante el use after free.

En OpenHarmony v3.2.4 y versiones anteriores permiten que un atacante local ejecute código arbitrario en cualquier aplicación mediante una entrada incorrecta.

En OpenHarmony v3.2.4 y versiones anteriores permiten que un atacante local provoque DOS a través de un desbordamiento de pila.

Se descubrió un problema en seeyonOA versión 8, que permite a atacantes remotos ejecutar código arbitrario a través del método importProcess en el componente WorkFlowDesignerController.class.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/lib: vuelva a _ASM_EXTABLE_UA() para reparaciones de {get,put}_user() Durante la prueba de inyección de errores de memoria en kernels >= v6.4, el kernel entra en pánico como se muestra a continuación. Sin embargo, este problema no se pudo reproducir en kernels <= v6.3. mce: [Error de hardware]: CPU 296: Excepción de verificación de la máquina: f Banco 1: bd80000000100134 mce: [Error de hardware]: RIP 10: {__get_user_nocheck_4+0x6/0x20} mce: [Error de hardware]: TSC 411a93533ed ADDR 346a87300 40 MISC 86 mce: [Error de hardware]: PROCESADOR 0:a06d0 HORA 1706000767 SOCKET 1 APIC 211 microcódigo 80001490 mce: [Error de hardware]: Ejecute lo anterior a través de 'mcelog --ascii' mce: [Error de hardware]: Verificación de la máquina: Carga de datos en un área irrecuperable del kernel Pánico del kernel - no se sincroniza: verificación fatal de la máquina local El código MCA se puede recuperar de un #MC en el kernel si el tipo de reparación es EX_TYPE_UACCESS, lo que indica explícitamente que el kernel está intentando acceder a la memoria del espacio de usuario. Sin embargo, si el tipo de reparación es EX_TYPE_DEFAULT, lo único que se genera para un #MC en el kernel es pánico. ex_handler_uaccess() advertiría si los usuarios proporcionaban direcciones no canónicas (con el bit 63 claro) a {get, put}_user(), lo cual era inesperado. Por lo tanto, el commit b19b74bc99b1 ("x86/mm: Reelaborar la verificación del rango de direcciones en get_user() y put_user()") reemplazó _ASM_EXTABLE_UA() con _ASM_EXTABLE() para las correcciones de {get, put}_user(). Sin embargo, el nuevo tipo de reparación EX_TYPE_DEFAULT provoca pánico. El commit 6014bc27561f ("x86-64: hacer que access_ok() sea independiente de LAM") agregó la verificación gp_fault_address_ok() justo antes de WARN_ONCE() en ex_handler_uaccess() para no advertir sobre direcciones de usuarios no canónicas debido a LAM. Una vez implementado esto, vuelva a _ASM_EXTABLE_UA() para corregir excepciones de {get,put}_user() para poder manejar correctamente los MCE en el kernel nuevamente. [pb: mensaje de commit. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ppp_async: limitar MRU a 64K syzbot activó una advertencia [1] en __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem solucionó un problema similar en el commit c0a2a1b0d631 ("ppp: limite MRU a 64K") Adopte la misma verificación de cordura para ppp_async_ioctl(PPPIOCSMRU) [1]: ADVERTENCIA: CPU: 1 PID: 11 en mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Módulos vinculados en: CPU: 1 PID: 11 Comm: kworker/u4:0 No contaminado 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: events_unbound flux_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp: ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000 939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff8000939671 20 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 00000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9: 0000000000000001 x8: ffff800091c 91000 x7: 0000000000000000 x6: 000000000000003f x5: 00000000ffffffff x4: 0000000000000000 x3: 00000000000000020 x2: 0000000000000008 x1: 0000000000000000 x0: ffff8000939675e0 Rastreo de llamadas: __alloc_pages+0x308/ 0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [en línea] alloc_pages_node include/linux/gfp.h:261 [en línea] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub .c:3969 [en línea] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0x b8 /0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [en línea] dev_alloc_skb include/linux/skbuff.h:3248 [en línea] ppp_async_input drivers/net/ppp/ppp_async.c:863 [ en línea] ppp_asynctty_receive+0x588/0x186c controladores/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c controladores/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac controladores/tty/tty_port.c:37 recibir_buf controladores /tty /tty_buffer.c:444 [en línea] Flush_to_ldisc+0x284/0x6e4 controladores/tty/tty_buffer.c:494 Process_one_work+0x694/0x1204 kernel/workqueue.c:2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] trabajador_thread+0x938/ 0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: Llame a kfree_skb() para unix_(sk)->oob_skb muerto en GC. syzbot informó una advertencia [0] en __unix_gc() con una reproducción, que crea un par de sockets y se envía el fd de un socket a sí mismo utilizando el par. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 Esto forma una referencia autocíclica ese GC finalmente debería desenredarse, pero no lo hace debido a la falta de manejo de MSG_OOB, lo que resulta en una pérdida de memoria. Recientemente, el commit 11498715f266 ("af_unix: Eliminar el código io_uring para GC.") eliminó el código inactivo de io_uring en GC y reveló el problema. El código se ejecutó en la etapa final de GC y movió incondicionalmente todos los candidatos de GC de gc_candidates a gc_inflight_list. Eso ocultó el problema informado haciendo siempre que lo siguiente WARN_ON_ONCE(!list_empty(&gc_candidates)) fuera falso. El problema ha estado ahí desde que el commit 2aab4b969002 ("af_unix: corrige fugas de struct pid en soporte OOB") agregó soporte completo de scm para MSG_OOB mientras solucionaba otro error. Para solucionar este problema, debemos llamar a kfree_skb() para unix_sk(sk)->oob_skb si el socket todavía existe en gc_candidates después de purgar el skb recopilado. Luego, necesitamos establecer NULL en oob_skb antes de llamar a kfree_skb() porque llama al último fput() y activa unix_release_sock(), donde llamamos al duplicado kfree_skb(u->oob_skb) si no es NULL. Tenga en cuenta que el socket filtrado seguía vinculado a una lista global, por lo que kmemleak tampoco pudo detectarlo. Necesitamos verificar /proc/net/protocol para notar el socket no liberado. [0]: ADVERTENCIA: CPU: 0 PID: 2863 en net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Módulos vinculados en: CPU: 0 PID: 2863 Comm: kworker/ u4:11 No contaminado 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Cola de trabajo: events_unbound __unix_gc RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345 Código: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8 RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff c9000b03fc10 RCX: ffffffff816c493e RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30 RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66 R10: 00000000000000003 R11: 00000000000000002 R12: dffffc 0000000000 R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:000 0000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 00000000 00000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: Process_one_work+0x889/0x15e0 kernel/workqueue.c :2633 Process_scheduled_works kernel/workqueue.c:2706 [en línea] work_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process. c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrige los ACK retrasados para no establecer el número de serie de referencia. Se corrige la construcción de los ACK retrasados para no establecer el número de serie de referencia, ya que no se pueden usar como referencia RTT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/efistub: use archivo 1:1: mapeo de memoria para PE/COFF sección .compat La sección .compat es una sección PE ficticia que contiene la dirección del punto de entrada de 32 bits de la imagen del kernel de 64 bits si se puede iniciar desde firmware de 32 bits (es decir, CONFIG_EFI_MIXED=y) Esta sección tiene solo 8 bytes de tamaño y solo se hace referencia a ella desde el cargador, por lo que se coloca al final de la memoria. vista de la imagen, para evitar la necesidad de rellenarla a 4k, lo cual es necesario para las secciones que aparecen en el medio de la imagen. Desafortunadamente, esto viola la especificación PE/COFF, e incluso si la mayoría de los cargadores EFI funcionan correctamente (incluida la implementación de referencia de Tianocore), existen cargadores PE que rechazan dichas imágenes, basándose en que tanto las vistas de archivo como de memoria del contenido del archivo deben ser descritos por los encabezados de las secciones de manera monótonamente creciente sin dejar espacios en blanco. Así que reorganice las secciones para evitar este problema. Esto da como resultado una ligera sobrecarga de relleno (< 4k) que se puede evitar si se desea deshabilitando CONFIG_EFI_MIXED (que solo es necesario en casos excepcionales en estos días)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: inet: lee sk->sk_family una vez en inet_recv_error() se llama a inet_recv_error() sin mantener el bloqueo del socket. El socket IPv6 podría mutar a IPv4 con la opción de socket IPV6_ADDRFORM y generar una advertencia de KCSAN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: atlantic: corrige el mapeo DMA para el anillo PTP hwts. La función aq_ring_hwts_rx_alloc() asigna bytes AQ_CFG_RXDS_DEF adicionales para el anillo PTP HWTS, pero luego el aq_ring_free() genérico no tiene esto en cuenta. Cree y utilice una función específica para liberar el anillo HWTS y solucionar este problema. Seguimiento: [215.351607] ------------[ cortar aquí ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: el controlador de dispositivo se libera Memoria DMA con diferente tamaño [dirección del dispositivo=0x00000000fbdd0000] [tamaño del mapa=34816 bytes] [tamaño de desasignación=32768 bytes] [215.351635] ADVERTENCIA: CPU: 33 PID: 10759 en kernel/dma/debug.c:988 check_unmap+0xa6f/ 0x2360... [215.581176] Seguimiento de llamadas: [215.583632] [215.585745]? show_trace_log_lvl+0x1c4/0x2df [215.590114]? show_trace_log_lvl+0x1c4/0x2df [215.594497]? debug_dma_free_coherent+0x196/0x210 [215.599305]? check_unmap+0xa6f/0x2360 [215.603147]? __advertir+0xca/0x1d0 [215.606391] ? check_unmap+0xa6f/0x2360 [215.610237]? report_bug+0x1ef/0x370 [215.613921]? handle_bug+0x3c/0x70 [215.617423]? exc_invalid_op+0x14/0x50 [215.621269]? asm_exc_invalid_op+0x16/0x20 [215.625480]? check_unmap+0xa6f/0x2360 [215.629331]? mark_lock.part.0+0xca/0xa40 [215.633445] debug_dma_free_coherent+0x196/0x210 [215.638079]? __pfx_debug_dma_free_coherent+0x10/0x10 [215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlántico] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlántico]... [216.127540] ---[fin de seguimiento 6467e5964dd2640b]- -- [ 216.132160] DMA-API: Asignado en: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150 /0x1f0 [atlántico] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlántico] [216.132213] aq_nic_init+0x4a1/0x760 [atlántico]