Vulnerabilidades

NVIDIA TensorRT-LLM para cualquier plataforma contiene una vulnerabilidad en el ejecutor de Python que permite a un atacante causar un problema de validación de datos mediante el acceso local al servidor TRTLLM. Una explotación exitosa de esta vulnerabilidad puede provocar la ejecución de código, la divulgación de información y la manipulación de datos.

La carga de archivos sin restricciones en Kibana permite que un atacante autenticado comprometa la integridad del software al cargar un archivo malicioso manipulado debido a una validación insuficiente del lado del servidor.

El software NVIDIA vGPU para Windows y Linux contiene una vulnerabilidad en el Administrador de GPU Virtual (complemento vGPU), que permite a un invitado acceder a recursos globales. Una explotación exitosa de esta vulnerabilidad podría provocar una denegación de servicio.

Los registros del servidor APM podrían contener partes del cuerpo del documento de una solicitud de indexación masiva parcialmente fallida. Dependiendo de la naturaleza del documento, esto podría revelar información confidencial en los registros de errores del servidor APM.

La inclusión de funcionalidad de una esfera de control no confiable en el subproceso de Elastic Agent, osqueryd, permite a atacantes locales ejecutar código arbitrario mediante la inyección de parámetros. Un atacante requiere acceso local y la capacidad de modificar las configuraciones de osqueryd.

El consumo descontrolado de recursos en Elasticsearch al evaluar plantillas de búsqueda específicamente manipuladas con funciones Mustache puede provocar una denegación de servicio al provocar que el nodo Elasticsearch se bloquee.

La carga sin restricciones de un archivo con un tipo peligroso en Kibana puede provocar la ejecución arbitraria de JavaScript en el navegador de la víctima (XSS) mediante archivos HTML y JavaScript manipulados. El atacante debe tener acceso a la aplicación Synthetics y/o acceso para escribir en los índices de Synthetics.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/cpumf: Se corrige la doble liberación en caso de error en cpumf_pmu_event_init(). En las funciones de inicialización de eventos de PMU (cpumsf_pmu_event_init(), cpumf_pmu_event_init() y cfdiag_event_init()), el evento parcialmente creado debía eliminarse al detectarse un error. La función miembro event::event_init() debía liberar todos los recursos asignados en caso de error. Event::destroy() debía llamarse al liberar un evento después de su creación exitosa y event::event_init() devolvía la operación correcta. Con la confirmación c70ca298036c ("perf/core: Simplificar la ruta de error de perf_event_alloc()"), esto ya no es necesario. El código común del subsistema de rendimiento ahora siempre llama a event::destroy() para limpiar los recursos asignados creados durante la inicialización del evento. Elimine la invocación de event::destroy() en la inicialización de eventos de PMU, ya que dicha función se llama dos veces por cada evento que presenta una condición de error durante su creación. Esta es la entrada del registro del kernel que aparece sin la corrección: ------------[ cortar aquí ]------------ refcount_t: underflow; use-after-free. ADVERTENCIA: CPU: 0 PID: 43388 en lib/refcount.c:87 refcount_dec_not_one+0x74/0x90 CPU: 0 UID: 0 PID: 43388 Comm: perf No contaminado 6.15.0-20250407.rc1.git0.300.fc41.s390x+git #1 NINGUNO Nombre del hardware: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704c00180000000 00000209cb2c1b88 (refcount_dec_not_one+0x78/0x90) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 0000020900000027 0000020900000023 0000000000000026 0000018900000000 00000004a2200a00 0000000000000000 0000000000000057 ffffffffffffffea 00000002b386c600 00000002b3f5b3e0 00000209cc51f140 00000209cc7fc550 0000000001449d38 ffffffffffffffff 00000209cb2c1b84 00000189d67dfb80 Krnl Code: 00000209cb2c1b78: c02000506727 larl %r2,00000209cbcce9c6 00000209cb2c1b7e: c0e5ffbd4431 brasl %r14,00000209caa6a3e0 #00000209cb2c1b84: af000000 mc 0,0 >00000209cb2c1b88: a7480001 lhi %r4,1 00000209cb2c1b8c: ebeff0a00004 lmg %r14,%r15,160(%r15) 00000209cb2c1b92: ec243fbf0055 risbg %r2,%r4,63,191,0 00000209cb2c1b98: 07fe bcr 15,%r14 00000209cb2c1b9a: 47000700 bc 0,1792 Call Trace: [<00000209cb2c1b88>] refcount_dec_not_one+0x78/0x90 [<00000209cb2c1dc4>] refcount_dec_and_mutex_lock+0x24/0x90 [<00000209caa3c29e>] hw_perf_event_destroy+0x2e/0x80 [<00000209cacaf8b4>] __free_event+0x74/0x270 [<00000209cacb47c4>] perf_event_alloc.part.0+0x4a4/0x730 [<00000209cacbf3e8>] __do_sys_perf_event_open+0x248/0xc20 [<00000209cacc14a4>] __s390x_sys_perf_event_open+0x44/0x50 [<00000209cb8114de>] __do_syscall+0x12e/0x260 [<00000209cb81ce34>] system_call+0x74/0x98 Last Breaking-Event-Address: [<00000209caa6a4d2>] __warn_printk+0xf2/0x100 ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_pxa: Se corrige la posible desreferencia de punteros nulos en pxa_ata_probe(). Devm_ioremap() devuelve NULL en caso de error. Actualmente, pxa_ata_probe() no verifica este caso, lo que puede provocar una desreferencia de punteros nulos. Agregue la comprobación de NULL después de devm_ioremap() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: se corrige una fuga de memoria en tipc_link_xmit. Si la cola de transmisión de mensajes importantes del sistema está sobrecargada, tipc_link_xmit() devuelve -ENOBUFS, pero la lista de skb no se purga. Esto provoca una fuga de memoria y un fallo al asignar un skb. Esta confirmación corrige este problema purgando la lista de skb antes del retorno de tipc_link_xmit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tls: explícitamente deshabilitar la desconexión. syzbot descubrió que puede desconectar un socket TLS y luego encontrarse con todo tipo de casos inesperados. Recuerdo vagamente que Eric nos lo señaló hace mucho tiempo. Admitir la desconexión es muy difícil; por ejemplo, si la descarga está habilitada, tendríamos que esperar a que se ackearan todos los paquetes. La desconexión no se usa comúnmente; deshabilitarla. El problema inmediato con el que se encuentra syzbot es la advertencia en el strp, pero ese es simplemente el error más fácil de activar: ADVERTENCIA: CPU: 0 PID: 5834 en net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Rastreo de llamada: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [en línea] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: error en el controlador page_pool_dev_alloc_pages. page_pool_dev_alloc_pages podría devolver NULL. Se ejecutó un WARN_ON(!page), pero seguía usando el puntero NULL y se bloqueaba. Esto es similar a la confirmación 001ba0902046 ("net: fec: error en el controlador page_pool_dev_alloc_pages"). Esta vulnerabilidad fue detectada por nuestra herramienta de análisis estático Knighter.