Vulnerabilidades

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.

TOTOLINK A810R V4.1.2cu.5182_B20201026 es vulnerable a un desbordamiento de búfer en downloadFlile.cgi.

Al analizar ciertos archivos PLY malformados, la versión 1.14.1 de PCL se bloquea debido a una excepción std::out_of_range no detectada en PCLPointCloud2::at. Este problema podría aprovecharse para provocar un ataque de denegación de servicio (DoS) al procesar archivos PLY que no son de confianza.

Se descubrió que TOTOLINK EX200 v4.0.3c.7646_B20201211 contenía una vulnerabilidad de inserción de comandos en la función setUssd. Esta vulnerabilidad permite a un atacante ejecutar comandos arbitrarios a través del parámetro "ussd".

TOTOLINK A810R V4.1.2cu.5182_B20201026 es vulnerable a un desbordamiento de búfer en infostat.cgi.

authentik es un proveedor de identidad de código abierto. Las URI de redireccionamiento en el proveedor OAuth2 en authentik se verifican mediante una comparación de RegEx. Cuando no se configuran URI de redireccionamiento en un proveedor, authentik usará automáticamente el primer valor redirect_uri recibido como una URI de redireccionamiento permitida, sin escapar caracteres que tengan un significado especial en RegEx. De manera similar, la documentación tampoco tomó esto en consideración. Dado un proveedor con las URI de redireccionamiento configuradas en https://foo.example.com, un atacante puede registrar un dominio fooaexample.com y pasará la validación correctamente. authentik 2024.8.5 y 2024.10.3 solucionan este problema. Como workaround, al configurar proveedores OAuth2, asegúrese de escapar cualquier carácter comodín que no esté destinado a funcionar como comodín, por ejemplo, reemplace `.` con `\.`.

authentik es un proveedor de identidad de código abierto. Debido al uso de una comparación de tiempo no constante para el endpoint /-/metrics/, fue posible forzar la SECRET_KEY, que se utiliza para autenticar el endpoint. El endpoint /-/metrics/ devuelve métricas de Prometheus y no está destinado a ser accedido directamente, ya que el proxy Go que se ejecuta en el contenedor del servidor authentik obtiene datos de este endpoint y los entrega en un puerto separado (9300 de manera predeterminada), que Prometheus puede extraer sin exponerlo públicamente. authentik 2024.8.5 y 2024.10.3 solucionan este problema. Dado que el endpoint /-/metrics/ no está destinado a ser accedido públicamente, las solicitudes al endpoint pueden ser bloqueadas por el proxy inverso/balanceador de carga utilizado junto con authentik.

SFTPGo es un servidor SFTP, HTTP/S, FTP/S y WebDAV con todas las funciones y altamente configurable: S3, Google Cloud Storage, Azure Blob. Una característica poderosa de SFTPGo es la capacidad de hacer que EventManager ejecute scripts o ejecute aplicaciones en respuesta a ciertos eventos. Esta característica es muy común en todo el software similar a SFTPGo y generalmente no tiene restricciones. Sin embargo, cualquier administrador de SFTPGo con permiso para ejecutar un script tiene acceso al sistema operativo/contenedor subyacente con los mismos permisos que el usuario que ejecuta SFTPGo. Esto es inesperado para algunos administradores de SFTPGo que piensan que existe una distinción clara entre acceder al shell del sistema y acceder a la interfaz de usuario de WebAdmin de SFTPGo. Para evitar esta confusión, la ejecución de comandos del sistema está deshabilitada de forma predeterminada en 2.6.3 y se agregó una lista de permitidos para que los administradores del sistema que configuren SFTPGo deban definir explícitamente qué comandos se pueden configurar desde la interfaz de usuario de WebAdmin.