Vulnerabilidades

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.

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: txgbe: se corrige pérdida de memoria en la ruta de error txgbe_probe() Cuando se llama a txgbe_sw_init(), se asigna memoria para wx->rss_key en wx_init_rss_key(). Sin embargo, en la función txgbe_probe(), las rutas de error posteriores a txgbe_sw_init() no liberan rss_key. Arréglelo liberándolo en la ruta de error junto con wx->mac_table. Cambie también la etiqueta a la que salta la ejecución cuando falla txgbe_sw_init(), porque de lo contrario, podría provocar una doble liberación de rss_key, cuando falla la asignación de mac_table en wx_sw_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: se corrige la falta de recorte del índice de anillo en la ruta de error. La confirmación bajo "Correcciones" convirtió tx_prod para que se ejecutara libremente, pero no lo enmascaró en la ruta de error de Tx. Esto falla en condiciones de error, por ejemplo, cuando falla la asignación de DMA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ngbe: corrección de pérdida de memoria en la ruta de error de ngbe_probe() Cuando se llama a ngbe_sw_init(), se asigna memoria para wx->rss_key en wx_init_rss_key(). Sin embargo, en la función ngbe_probe(), las rutas de error posteriores a ngbe_sw_init() no liberan rss_key. Solucione esto liberándolo en la ruta de error junto con wx->mac_table. Cambie también la etiqueta a la que salta la ejecución cuando falla ngbe_sw_init(), porque de lo contrario, podría provocar una doble liberación de rss_key, cuando falla la asignación de mac_table en wx_sw_init().