Vulnerabilidades

El complemento 1 Click WordPress Migration Plugin – 100% FREE for a limited time para WordPress es vulnerable a la modificación no autorizada de datos debido a la falta de comprobación de la función «start_restore» en todas las versiones hasta la 2.2 incluida. Esto permite que atacantes autenticados, con acceso de suscriptor o superior, carguen archivos arbitrarios en el servidor del sitio afectado, lo que podría posibilitar la ejecución remota de código.

El complemento Frontend Login and Registration Blocks para WordPress es vulnerable a la escalada de privilegios mediante el robo de cuenta en todas las versiones hasta la 1.0.7 incluida. Esto se debe a que el complemento no valida correctamente la identidad del usuario antes de actualizar sus datos, como el correo electrónico, mediante la función flr_blocks_user_settings_handle_ajax_callback(). Esto permite que atacantes no autenticados cambien las direcciones de correo electrónico de usuarios arbitrarios, incluidos los administradores, y aprovechen esta situación para restablecer la contraseña del usuario y acceder a su cuenta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: aspeed: Se ha añadido una comprobación de puntero nulo en ast_vhub_init_dev(). La variable d->name, devuelta por devm_kasprintf(), podría ser nula. Se ha añadido una comprobación de puntero para evitar posibles desreferencias de punteros nulos. Esto es similar a la corrección en la confirmación 3027e7b15b02 ("ice: Se corrigen algunos problemas de desreferencia de puntero nulo en ice_ptp.c"). Nuestra herramienta de análisis estático ha detectado este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Arreglar el manejo de eventos isócronos de Infraeje/Desbordamiento de Anillo El puntero TRB de estos eventos apunta a enqueue en el momento de ocurrencia del error en HCs xHCI 1.1+ o es NULL en los más antiguos. En el momento en que manejamos el evento, un nuevo TD puede estar en cola en esta posición de anillo. Puedo desencadenar esta ejecución aumentando la moderación de interrupciones para aumentar el retraso en el manejo de IRQ. Un retraso similar puede ocurrir naturalmente debido a la carga del sistema. Si esto sucede alguna vez después de un Error de Servicio Perdido, los TD perdidos se omitirán y el nuevo TD se procesará como si coincidiera con el evento. Podría devolverse prematuramente, con el riesgo de pérdida de datos o UAF de búfer por parte del xHC. No complete los TD en eventos xrun y no advierta si los TD en cola no coinciden con el puntero TRB del evento, que puede ser NULL o un TRB de enlace/no operación. No avisar si no hay ningún TD en cola. Ahora que es seguro, también se gestionan los eventos xrun si el indicador de omisión está desactivado. Esto garantiza la finalización de cualquier TD bloqueado en estado de "error a mitad de TD" justo antes del evento xrun, lo que podría ocurrir si un controlador envía un número finito de URB a un HC con errores y luego se produce un error en el último TD.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/sclp: Se ha añadido una comprobación para get_zeroed_page(). Se ha añadido una comprobación del valor de retorno de get_zeroed_page() en sclp_console_init() para evitar la desreferencia de punteros nulos. Además, para solucionar la fuga de memoria causada por la asignación de bucles, se ha añadido un asistente gratuito para realizar la tarea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Restablecer IRTE al control del host si la *nueva* ruta no se puede publicar. Restaurar un IRTE al control del host (modo MSI reasignado o publicado) si la *nueva* ruta GSI impide publicar la IRQ directamente a una vCPU, independientemente del tipo de enrutamiento de GSI. Actualizar el IRTE solo si la nueva GSI es una MSI hace que KVM deje una publicación de IRTE en una vCPU. El IRTE pendiente puede provocar que las interrupciones se entreguen incorrectamente al invitado y, en el peor de los casos, puede provocar un use-after-free, por ejemplo, si se desactiva la máquina virtual, pero no se libera la IRQ del host subyacente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pds_core: hacer que wait_context forme parte de q_info Hacer que wait_context sea una parte completa de la estructura q_info en lugar de una variable de pila que desaparezca después de que pdsc_adminq_post() se complete para que el contexto siga disponible después de que el bucle de espera se haya dado por vencido. Hubo un caso en el que un firmware de desarrollo lento provocó que la solicitud adminq expirara, pero luego el FW finalmente terminó la solicitud y envió la interrupción. El controlador intentó completar_todo() el contexto de finalización que se había creado en la pila en pdsc_adminq_post() pero ya no existía. Esto causó un mal uso del puntero, fallos del kernel y muchos lamentos y crujir de dientes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/net: se corrige el manejo incorrecto de respuestas de lectura/escritura negativas falsas. En p9_client_write() y p9_client_read_once(), si el servidor responde incorrectamente con éxito, pero con un recuento de escrituras/lecturas negativo, se consideraría que "escrito" (negativo) <= "rsize" (positivo) porque ambas variables estaban firmadas. Para evitar este problema, desactive el signo de las variables. El reproductor enlazado a continuación ahora falla con el siguiente error en lugar de una referencia de puntero nulo: 9pnet: recuento de RWRITE falso (4294967295 > 3)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: solución alternativa para que sched_yield no ceda en modo de viaje en el tiempo. Es posible que la ejecución de sched_yield por un espacio de usuario no provoque la programación en modo de viaje en el tiempo, ya que no ha transcurrido tiempo. En el caso observado, parece tratarse de un bloqueo de giro del espacio de usuario mal implementado en ASAN. Desafortunadamente, con el viaje en el tiempo, causa una ralentización extrema o incluso un bloqueo, dependiendo de la configuración del kernel (CONFIG_UML_MAX_USERSPACE_ITERATIONS). Para solucionarlo, se contabiliza el tiempo del proceso cada vez que ejecuta una llamada al sistema sched_yield.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: Arregla WARN_ON(!ctx) en __free_event() para init parcial Mueve la llamada get_ctx(child_ctx) y la asignación child_event->ctx para que ocurran inmediatamente después de que se asigne el evento secundario. Asegúrate de que child_event->ctx no sea NULL antes de cualquier ruta de error posterior dentro de las llamadas heritage_event a free_event(), satisfaciendo las suposiciones del código de limpieza. Detalles: No hay una etiqueta Fixes clara, porque este error es un efecto secundario de múltiples confirmaciones interactivas a lo largo del tiempo (hasta 15 años de antigüedad), no una sola regresión. El código inicialmente incrementó refcount y luego asignó contexto inmediatamente después de que se creara child_event. Más tarde, se agregó una comprobación de validez temprana para child_event antes de refcount/assignment. Incluso más tarde, se agregó una comprobación de limpieza WARN_ON_ONCE(), asumiendo que event->ctx es válido si pmu_ctx es válido. El problema radica en que WARN_ON_ONCE() podría activarse después de que se supere la comprobación inicial, pero antes de que se asignara child_event->ctx, incumpliendo su precondición. La solución es asignar child_event->ctx justo después de su validación inicial. Esto garantiza la existencia del contexto para cualquier comprobación o rutina de limpieza posterior, resolviendo WARN_ON_ONCE(). Para solucionarlo, posponga la actualización del recuento de referencias y la asignación de child_event->ctx justo después de que se configure child_event->pmu_ctx, pero antes de comprobar si el evento principal está huérfano. La rutina de limpieza depende de que event->pmu_ctx no sea NULL antes de verificar que event->ctx no sea NULL. Esto también mantiene la intención original del autor de pasar child_ctx a find_get_pmu_context antes de su recuento de referencias/asignación. [mingo: Registro de cambios ampliado de otro correo electrónico de Gabriel Shahrouzi].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige el bloqueo entre rcu_tasks_trace y event_mutex. Se corrige el siguiente bloqueo: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegue trace_set_clr_event() a workqueue para evitar dicha dependencia de bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: impide el bloqueo en caso de fallo del entrenamiento del enlace [Por qué] Cuando el entrenamiento del enlace falla, el reloj físico se desactiva. Sin embargo, en enable_streams, se asume que el entrenamiento del enlace se realizó correctamente y el multiplexor selecciona el reloj físico, lo que provoca un bloqueo al escribir en un registro. [Cómo] Cuando se alcanza enable_stream, se comprueba si el entrenamiento del enlace ha fallado. En caso afirmativo, se recurre al reloj de referencia para evitar un bloqueo y mantener el sistema en un estado recuperable.