Vulnerabilidades

Se encontró una vulnerabilidad en SourceCodester Online Student Clearance System 1.0. Se ha declarado crítica. Esta vulnerabilidad afecta al código desconocido del archivo /admin/edit-admin.php. La manipulación del argumento txtfullname/txtemail/cmddesignation provoca una inyección SQL. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.

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: 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: 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: 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: 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: 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: 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: 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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: disminuir sc_count directamente si no se puede poner en cola dl_recall Se produjo una advertencia de bloqueo al invocar nfs4_put_stid después de una operación de cola dl_recall fallida: T1 T2 nfs4_laundromat nfs4_get_client_reaplist nfs4_anylock_blockers __break_lease spin_lock // ctx->flc_lock spin_lock // clp->cl_lock nfs4_lockowner_has_blockers locks_owner_has_blockers spin_lock // flctx->flc_lock nfsd_break_deleg_cb nfsd_break_one_deleg nfs4_put_stid refcount_dec_and_lock spin_lock // clp->cl_lock Cuando se abre un archivo, se genera una nfs4_delegation asignado con sc_count inicializado a 1, y el file_lease contiene una referencia a la delegación. El file_lease se asocia entonces con el archivo a través de kernel_setlease. La disociación se realiza en nfsd4_delegreturn mediante la siguiente cadena de llamadas: nfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg --> nfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_lease La referencia sc_count correspondiente se liberará después de esta disociación. Dado que nfsd_break_one_deleg se ejecuta mientras mantiene el flc_lock, el proceso de disociación se bloquea al intentar adquirir flc_lock en generic_delete_lease. Esto significa: 1) sc_count en nfsd_break_one_deleg no se decrementará a 0; 2) El `nfs4_put_stid` llamado por `nfsd_break_one_deleg` no intentará adquirir `cl_lock`; 3) Por consiguiente, no se crea ninguna condición de interbloqueo. Dado que `sc_count` en `nfsd_break_one_deleg` permanece distinto de cero, podemos ejecutar `refcount_dec` en `sc_count` directamente. Este enfoque evita eficazmente la activación de advertencias de interbloqueo.