Vulnerabilidades

Una vulnerabilidad de carga de archivos arbitrarios en el método importSettings de VisiCut v2.1 permite a los atacantes ejecutar código arbitrario mediante la carga de un archivo Zip manipulado específicamente para ello.

Una vulnerabilidad de carga de archivos arbitrarios en el componente \Roaming\Omega de OmegaT v6.0.1 permite a los atacantes ejecutar código arbitrario mediante la carga de un archivo .conf manipulado específicamente.

Una vulnerabilidad de carga de archivos arbitrarios en el componente \Users\username.BlackBoard de BlackBoard v2.0.0.2 permite a los atacantes ejecutar código arbitrario mediante la carga de un archivo .xml manipulado específicamente.

Se descubrió que varios endpoints en `oracle-sidecar` en las versiones 0.347.0 a 0.543.0 eran vulnerables a inyecciones de SQL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Fix lock recursion afs_wake_up_async_call() puede generar recursión de bloqueo. El problema es que se llama desde AF_RXRPC mientras se mantiene el ->notify_lock, pero intenta tomar una referencia en la estructura afs_call para pasarla a una cola de trabajo; pero si afs_call ya está en cola, entonces tenemos una referencia extraña que se debe poner... sin embargo, llamar a afs_put_call() puede volver a llamar a AF_RXRPC a través de rxrpc_kernel_shutdown_call(), que podría intentar tomar el ->notify_lock nuevamente. Sin embargo, este caso no es muy común, por lo que se debe diferir a una cola de trabajo. El error se parece a algo como esto: ERROR: recursión de spinlock en CPU#0, krxrpcio/7001/1646 bloqueo: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 No contaminado 6.12.0-rc2-build3+ #4351 Nombre del hardware: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Seguimiento de llamadas: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_de_la_bifurcación+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_de_la_bifurcación_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Agregar comprobación de sk_is_inet e IS_ICSK en tls_sw_has_ctx_tx/rx Como la introducción del soporte para vsock y sockets unix en sockmap, tls_sw_has_ctx_tx/rx no puede presumir que el socket pasado debe ser IS_ICSK. Los sockets vsock y af_unix tienen vsock_sock y unix_sock en lugar de inet_connection_sock. Para estos sockets, tls_get_ctx puede devolver un puntero no válido y causar un error de página en la función tls_sw_ctx_rx. ERROR: no se puede manejar el error de página para la dirección: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_pci: Arreglar la limpieza de admin vq usando el puntero de información correcto vp_modern_avq_cleanup() y vp_del_vqs() limpian los recursos de admin vq mediante el puntero virtio_pci_vq_info. El puntero de información de admin vq se almacena en vp_dev->admin_vq.info en lugar de vp_dev->vqs[]. Usar el puntero de información de vp_dev->vqs[] para admin vq causa un error de desreferencia de puntero NULL en el kernel. En vp_modern_avq_cleanup() y vp_del_vqs(), obtener el puntero de información de vp_dev->admin_vq.info para admin vq para limpiar los recursos. También hacer que info ptr como argumento de vp_del_vq() sea simétrico con vp_setup_vq(). vp_reset llama a vp_modern_avq_cleanup y provoca el seguimiento de llamadas: ===================================================================== ERROR: desreferencia de puntero NULL del núcleo, dirección:000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe No contaminado 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Seguimiento de llamadas: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/siw: Agregar la comprobación sendpage_ok() para deshabilitar MSG_SPLICE_PAGES Mientras se ejecuta ISER sobre SIW, la máquina iniciadora encuentra una advertencia de skb_splice_from_iter() que indica que se está utilizando una página slab en send_page. Para solucionar esto, es mejor agregar una comprobación sendpage_ok() dentro del propio controlador y, si devuelve 0, entonces se debe deshabilitar el indicador MSG_SPLICE_PAGES antes de ingresar a la pila de red. Se ha discutido un problema similar para NVMe en este hilo: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ ADVERTENCIA: CPU: 0 PID: 5342 en net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Seguimiento de llamadas: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_de_la_bifurcación+0x34/0x40 ret_de_la_bifurcación_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: Fix use-after-free of network namespace. Recientemente, recibimos un informe de un cliente que indica que CIFS desencadena errores al reconectarse a un servidor. [0] La carga de trabajo se ejecuta en Kubernetes y algunos pods montan servidores CIFS en espacios de nombres de red que no son raíz. El problema rara vez sucedía, pero siempre sucedía mientras el pod se estaba muriendo. La causa raíz es un recuento de referencias incorrecto para el espacio de nombres de red. CIFS usa sockets de kernel, que no contienen refcnt de las netn a las que pertenece el socket. Eso significa que CIFS debe asegurarse de que el socket siempre se libere antes que sus netn; de lo contrario, se produce el use after free. Los pasos de reproducción son, a grandes rasgos: 1. montar CIFS en una red no raíz 2. descartar paquetes de la red 3. destruir la red 4. desmontar CIFS Podemos reproducir el problema rápidamente con el script [1] a continuación y ver el splat [2] si CONFIG_NET_NS_REFCNT_TRACKER está habilitado. Cuando el socket es TCP, es difícil garantizar la duración de la red sin mantener refcnt debido a los temporizadores asíncronos. Mantengamos netns refcnt para cada socket como se hizo para SMC en el commit 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler()."). Tenga en cuenta que debemos mover put_net() de cifs_put_tcp_session() a clean_demultiplex_info(); de lo contrario, __sock_create() aún podría tocar un netns liberado mientras cifsd intenta reconectarse desde cifs_demultiplex_thread(). Además, maybe_get_net() no se puede colocar justo antes de __sock_create() porque el código no está bajo RCU y existe una pequeña posibilidad de que la misma dirección se haya reasignado a otro netns. [0]: CIFS: VFS: \\XXXXXXXXXXX no ha respondido en 15 segundos. Reconectando... CIFS: Serverclose falló 4 veces, abandonando No se puede manejar la solicitud de paginación del núcleo en la dirección virtual 14de99e461f84a07 Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducción de nivel 0 Información de aborto de datos: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] dirección entre rangos de direcciones de usuario y núcleo Error interno: Oops: 0000000096000004 [#1] Módulos SMP vinculados en: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_estado xt_connmark nf_conntrack_netlink xt_nat xt_estadística xt_MASQUERADE xt_marca xt_tipo_dirección ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables superposición nfnetlink nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena botón sch_fq_codel bucle fusible configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd No contaminado 6.1.103-109.184.amzn2023.aarch64 #1 Nombre del hardware: Amazon EC2 r7g.4xlarge/, BIOS 1.0 1/11/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 0000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 00000000000000006 x6 : 0000000000000000 x5 : 00000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 ---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-multipath: aplazar el escaneo de particiones Necesitamos evitar que el escaneo de particiones se realice dentro del contexto scan_work del controlador. Si se produce un error de ruta aquí, la IO esperará hasta que haya una ruta disponible o se eliminen todas las rutas, pero esa acción también ocurre dentro de scan_work, por lo que se bloquearía. Aplaza el escaneo de particiones a un contexto diferente que no bloquee scan_work.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: Marcar hrtimer para que caduque en un contexto de interrupción dura Como en el commit 2c0d278f3293f ("KVM: LAPIC: Marcar hrtimer para que caduque en un contexto de interrupción dura") y el commit 9090825fa9974 ("KVM: arm/arm64: Dejar que el temporizador caduque en un contexto de hardirq en RT"), en los kernels con PREEMPT_RT habilitado, los hrtimers sin marcar se mueven al modo de caducidad de interrupción suave de forma predeterminada. Luego, los temporizadores se cancelan desde un notificador de preempción que se invoca con la preempción deshabilitada, lo que no está permitido en PREEMPT_RT. La devolución de llamada del temporizador es corta, por lo que podría invocarse en un contexto de hard-IRQ. Por lo tanto, deje que el temporizador caduque en un contexto de hard-IRQ incluso en -RT. Esto corrige un error de "programación mientras es atómico" para los kernels con PREEMPT_RT habilitado: ERROR: programación mientras es atómico: qemu-system-loo/1011/0x00000002 Módulos vinculados en: amdgpu rfkill 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 ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Contaminado: GW 6.12.0-rc2+ #1774 Contaminado: [W]=WARN Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 21/10/2022 Pila: ffffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 900000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 900000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Seguimiento de llamadas: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finalizar_conmutación_de_tareas.isra.0+0x140/0x2e0 [<9000000004e44a70>] __programación+0x450/0x1660 [<9000000004e45cb0>] programación+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]

La vulnerabilidad de cross site scripting en Gibbon anterior a v.27.0.01 y corregida en v.28.0.00 permite a un atacante remoto obtener información confidencial a través del parámetro de correo electrónico que se encuentra en /Gibbon/modules/User Admin/user_manage_editProcess.php.