Vulnerabilidades

Una vulnerabilidad fue encontrada en Tenda i22 1.0.0.3(4687) y clasificada como crítica. Esta vulnerabilidad afecta a la función formApPortalAccessCodeAuth del archivo /goform/apPortalAccessCodeAuth. La manipulación del argumento código de acceso/datos/acceInfo provoca un desbordamiento del búfer. El ataque se puede iniciar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: serial: mos7840: corrige el fallo al reanudar desde el commit c49cfa917025 ("USB: serial: use un método genérico si no se proporciona ninguna alternativa en la capa serial USB"), llamadas al núcleo serial USB la implementación del currículum genérico cuando el driver no lo haya proporcionado. Esto puede provocar un fallo en el currículum con mos7840 desde que se agregó soporte para múltiples URB de lectura en 2011. Específicamente, ambos URB de lectura de puerto ahora se envían en el currículum para puertos abiertos, pero el puntero de contexto del segundo URB se deja configurado en el núcleo en lugar de la estructura del puerto mos7840. Solucione este problema implementando funciones dedicadas de suspensión y reanudación para mos7840. Probado con el adaptador serie Delock 87414 USB 2.0 a 4x. [ johan: analiza el fallo y reescribe el mensaje de confirmación; establecer una bandera de ocupado en el currículum; dejar caer el cheque a granel; soltar usb_kill_urb() innecesario]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "programado/justo: asegúrese de intentar desconectar al menos una tarea móvil". Esto revierte el commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. b0defa7ae03ec cambió la lógica de equilibrio de carga para ignorar env.max_loop si todas las tareas examinadas hasta ese punto estaban fijadas. El objetivo del parche era hacer que fuera más probable poder separar una tarea oculta en una larga lista de tareas fijadas. Sin embargo, esto tiene el desafortunado efecto secundario de crear una iteración O(n) en detach_tasks(), ya que ahora debemos iterar completamente cada tarea en una CPU si todas o la mayoría están fijadas. Dado que este código de equilibrio de carga se realiza con el bloqueo rq mantenido y, a menudo, en el contexto de softirq, es muy fácil activar bloqueos duros. Observamos bloqueos tan difíciles con un usuario que afinó O(10k) subprocesos a una sola CPU. Cuando hablé de esto con Vincent, inicialmente sugirió que mantuviéramos el límite en la cantidad de tareas para separar, pero que incrementáramos la cantidad de tareas que podemos buscar. Sin embargo, después de algunos intercambios en la lista de correo, recomendó que revirtiéramos el parche original, ya que parece probable que nadie se haya visto afectado por el problema original.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net, sunrpc: reasignar EPERM en caso de falla de conexión en xs_tcp_setup_socket Cuando se usa un programa BPF en kernel_connect(), la llamada puede devolver -EPERM. Esto hace que xs_tcp_setup_socket() se repita indefinidamente, llenando el syslog y provocando que el kernel se congele potencialmente. Neil sugirió: Esto propagará -EPERM a otras capas que podrían no estar listas para manejarlo. Podría ser más seguro asignar EPERM a un error que probablemente esperaríamos del sistema de red, como ECONNREFUSED o ENETDOWN. ECONNREFUSED como error parece razonable. Para los programas, configurar un error diferente puede estar fuera de su alcance (consulte el manejo en 4fbac77d2d09), en particular en los núcleos que no tienen f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err en lugar de permitir boolean"), por lo que es mejor simplemente reasignar para un comportamiento consistente. UDP maneja EPERM en xs_udp_send_request().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wireguard: Allowips: evita accesos a memoria de 64 bits no alineados. En la plataforma Parisc, el kernel emite advertencias del kernel porque swap_endian() intenta cargar una dirección IPv6 de 128 bits desde una memoria no alineada. ubicación: Kernel: acceso no alineado a 0x55f4688c en wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: acceso no alineado a 0x55f46884 en wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc ) Evite dichos accesos a la memoria no alineados utilizando en su lugar get_unaligned_be64 () macro auxiliar. [Jason: reemplaza src[8] en el parche original con src+8]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: archivos de caché: agregue protección de bloqueo faltante al sondear. Agregue protección de bloqueo faltante en la rutina de sondeo al iterar xarray; de lo contrario: incluso con el bloqueo de lectura de RCU mantenido, solo se garantiza que la ranura del árbol de base ser anclado allí, mientras que la estructura de datos (por ejemplo, struct cachefiles_req) almacenada en la ranura no tiene tal garantía. La rutina de sondeo iterará el árbol de base y eliminará la referencia a cachefiles_req en consecuencia. Por lo tanto, el bloqueo de lectura de la RCU no es adecuado en este caso y aquí se necesita el bloqueo de giro.

Un problema en el módulo de información de hardware de IT Solutions Enjay CRM OS v1.0 permite a los atacantes escapar del entorno restringido del terminal y obtener privilegios de nivel superusuario en el sistema subyacente.

Se ha descubierto una vulnerabilidad de suplantación de IP en Likeshop hasta la versión 2.5.7.20210811. Este problema permite a un atacante reemplazar su dirección IP real con cualquier dirección IP arbitraria, específicamente agregando un encabezado falsificado 'X-Forwarded' o 'Client-IP' a las solicitudes. Al explotar la suplantación de IP, los atacantes pueden eludir los mecanismos de bloqueo de cuentas durante los intentos de iniciar sesión en cuentas de administrador, falsificar direcciones IP en solicitudes enviadas al servidor y hacerse pasar por direcciones IP que han iniciado sesión en cuentas de usuario, etc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: filemap: reemplace pte_offset_map() con pte_offset_map_nolock() El vmf->ptl en filemap_fault_recheck_pte_none() todavía está configurado desde handle_pte_fault(). Pero al mismo tiempo, hicimos un pte_unmap(vmf->pte). Después de desasignar pte_unmap(vmf->pte) y rcu_read_unlock(), la tabla de páginas puede cambiarse rápidamente y vmf->ptl tal vez no pueda proteger la tabla de páginas real. Solucione este problema reemplazando pte_offset_map() con pte_offset_map_nolock(). Como dijo David, el puntero PTL puede estar obsoleto, por lo que si continuamos usándolo en filemap_fault_recheck_pte_none(), podría activar UAF. Además, si el PTL falla, el problema solucionado mediante el commit 58f327f2ce80 ("filemap: evite errores importantes innecesarios en filemap_fault()") podría reaparecer.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: corrige fallas debido a la migración diferida de folios de ejecuciones divididas Incluso en 6.10-rc6, he estado viendo "estados de página incorrectos" esquivos (a menudo en indicadores al liberar, pero los indicadores mostrados no son malos: ¿PG_locked se había configurado y borrado?), y VM_BUG_ON_PAGE(page_ref_count(page) == 0)s de folio_put() de deferred_split_scan(), y una variedad de otros síntomas de ERROR y ADVERTENCIA que implican doble liberación por división diferida y migración de folios grandes. 6.7 el commit 9bcef5973e31 ("mm: memcg: corregir el bloqueo de la lista de colas divididas cuando se migra un folio grande") tenía razón al corregir el bloqueo dependiente de memcg roto en 85ce2c517ade ("memcontrol: transferir solo los datos de memcg para la migración"), pero omitió una sutileza de deferred_split_scan(): mueve las publicaciones a su propia lista local para trabajar en ellas sin split_queue_lock, tiempo durante el cual folio->_deferred_list no está vacío, pero ni siquiera el bloqueo "derecho" hace nada para proteger la publicación y la lista en la que se encuentra. Afortunadamente, deferred_split_scan() tiene cuidado al usar folio_try_get(): por lo que folio_migrate_mapping() puede evitar la ejecución mediante folio_undo_large_rmappable() mientras el recuento de referencias de la publicación anterior se congela temporalmente en 0; agregando dicha congelación también en el caso de !mapping (originalmente, El bloqueo y la desasignación de folios y la falta de caché de intercambio dejaron un folio anónimo inalcanzable, por lo que no fue necesario congelarlo allí: pero la cola dividida diferida ofrece una forma de acceder a él).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/mm: agregue verificación de puntero NULL a crst_table_free() base_crst_free() crst_table_free() solía trabajar con punteros NULL antes de la conversión a ptdescs. Dado que crst_table_free() se puede llamar con un puntero NULL (el manejo de errores en crst_table_upgrade() agrega una verificación explícita. También agregue la misma verificación a base_crst_free() por razones de coherencia. En la vida real, esto no debería suceder, ya que ordenar dos asignaciones GFP_KERNEL no falla, a menos que FAIL_PAGE_ALLOC esté habilitado y utilizado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: falla bpf_timer_cancel cuando se cancela la devolución de llamada. Dada una programación: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Ambas llamadas a bpf_timer_cancel esperarían a que la otra devolución de llamada termine de ejecutarse, introduciendo un bloqueo. Agregue un recuento atomic_t llamado 'cancelación' en bpf_hrtimer. Esto realiza un seguimiento de todas las solicitudes de cancelación en vuelo para un temporizador BPF determinado. Siempre que cancelemos un temporizador BPF, debemos verificar si tenemos solicitudes de cancelación pendientes y, de ser así, debemos fallar la operación con un error (-EDEADLK) ya que la cancelación es sincrónica y espera a que termine de ejecutarse la devolución de llamada. Esto implica que podemos entrar en una situación de punto muerto que involucre dos o más devoluciones de llamada de temporizador ejecutándose en paralelo e intentando cancelarse entre sí. Tenga en cuenta que evitamos incrementar el contador de cancelación para el temporizador de destino (el que se cancela) si no se invoca bpf_timer_cancel desde una devolución de llamada, para evitar errores falsos. El objetivo de detectar cur->cancelar y devolver -EDEADLK es no ingresar a un ciclo de espera ocupado (que puede o no conducir a un bloqueo). Esto no se aplica en caso de que la persona que llama se encuentre en un contexto sin devolución de llamada; la otra parte puede continuar cancelando como mejor le parezca sin cometer errores. Antecedentes de intentos anteriores: Las versiones anteriores de este parche usaban un bit bool de 'cancelación' y usaban el siguiente patrón en temporizador->bloqueo para publicar el estado de cancelación. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; El almacén fuera de la sección crítica podría sobrescribir una asignación de cancelación t->de solicitudes paralelas a verdadero, para garantizar que la devolución de llamada que se ejecuta en paralelo observe su estado de cancelación. Sería necesario borrar este bit de cancelación una vez que se complete hrtimer_cancel, pero la falta de serialización introdujo ejecuciones. Se exploró otra opción donde bpf_timer_start borraría el bit al (re)iniciar el temporizador bajo temporizador->bloqueo. Esto garantizaría el acceso serializado al bit de cancelación, pero puede permitir que se borre antes de que hrtimer_cancel en vuelo haya terminado de ejecutarse, de modo que los bloqueos puedan ocurrir nuevamente. Por lo tanto, elegimos un contador atómico para realizar un seguimiento de todas las solicitudes de cancelación pendientes y lo utilizamos para evitar bloqueos en caso de que las devoluciones de llamada intenten cancelarse entre sí mientras se ejecutan en paralelo.