Vulnerabilidades

Buffer Overflow vulnerability in Vigor2620/LTE200 3.9.8.9 and earlier and Vigor2860/2925 3.9.8 and earlier and Vigor2862/2926 3.9.9.5 and earlier and Vigor2133/2762/2832 3.9.9 and earlier and Vigor165/166 4.2.7 and earlier and Vigor2135/2765/2766 4.4.5.1 and earlier and Vigor2865/2866/2927 4.4.5.3 and earlier and Vigor2962/3910 4.3.2.8/4.4.3.1 and earlier and Vigor3912 4.3.6.1 and earlier allows a remote attacker to execute arbitrary code via the CGI parser's handling of the "Content-Length" header of HTTP POST requests.

Se descubrió que GFast entre v2 y v3.2 contenía una vulnerabilidad de inyección SQL a través del parámetro OrderBy en /system/operLog/list.

Se descubrió que los dispositivos Draytek Vigor 165/166 anteriores a la v4.2.6, Vigor 2620/LTE200 anteriores a la v3.9.8.8, Vigor 2860/2925 anteriores a la v3.9.7, Vigor 2862/2926 anteriores a la v3.9.9.4, Vigor 2133/2762/2832 anteriores a la v3.9.8, Vigor 2135/2765/2766 anteriores a la v4.4.5.1, Vigor 2865/2866/2927 anteriores a la v4.4.5.3, Vigor 2962/3910 anteriores a la v4.3.2.7, Vigor 3912 anteriores a la v4.3.5.2 y Vigor 2925 hasta la v3.9.6 no utilizaban la verificación de certificados, lo que permitía a los atacantes cargar módulos APPE manipulados desde servidores no oficiales, lo que lleva a la ejecución de código arbitrario.

Se descubrió que los dispositivos Draytek Vigor 165/166 anteriores a la v4.2.6, Vigor 2620/LTE200 anteriores a la v3.9.8.8, Vigor 2860/2925 anteriores a la v3.9.7, Vigor 2862/2926 anteriores a la v3.9.9.4, Vigor 2133/2762/2832 anteriores a la v3.9.8, Vigor 2135/2765/2766 anteriores a la v4.4.5.1, Vigor 2865/2866/2927 anteriores a la v4.4.5.3, Vigor 2962/3910 anteriores a la v4.3.2.7, Vigor 3912 anteriores a la v4.3.5.2 y Vigor 2925 hasta la v3.9.6 utilizan versiones inseguras de las funciones. strcmp y memcmp, lo que permite a los atacantes obtener información confidencial mediante ataques de tiempo.

Se descubrió que los dispositivos Draytek Vigor 165/166 anteriores a v4.2.6, Vigor 2620/LTE200 anteriores a v3.9.8.8, Vigor 2860/2925 anteriores a v3.9.7, Vigor 2862/2926 anteriores a v3.9.9.4, Vigor 2133/2762/2832 anteriores a v3.9.8, Vigor 2135/2765/2766 anteriores a v4.4.5.1, Vigor 2865/2866/2927 anteriores a v4.4.5.3, Vigor 2962/3910 anteriores a v4.3.2.7, Vigor 3912 anteriores a v4.3.5.2 y Vigor 2925 hasta v3.9.6 almacenaban contraseñas en texto plano.

Una desreferencia de puntero NULL en los dispositivos Draytek Vigor 165/166 anteriores a v4.2.6, Vigor 2620/LTE200 anteriores a v3.9.8.8, Vigor 2860/2925 anteriores a v3.9.7, Vigor 2862/2926 anteriores a v3.9.9.4, Vigor 2133/2762/2832 anteriores a v3.9.8, Vigor 2135/2765/2766 anteriores a v4.4.5.1, Vigor 2865/2866/2927 anteriores a v4.4.5.3, Vigor 2962/3910 anteriores a v4.3.2.7, Vigor 3912 anteriores a v4.3.5.2 y Vigor 2925 hasta v3.9.6 permite a los atacantes provocar una denegación de servicio (DoS) a través de una solicitud DHCP manipulada específicamente.

Un problema en el endpoint CGI utilizado para cargar configuraciones en dispositivos Draytek Vigor 165/166 anterior a v4.2.6, Vigor 2620/LTE200 anterior a v3.9.8.8, Vigor 2860/2925 anterior a v3.9.7, Vigor 2862/2926 anterior a v3.9.9.4, Vigor 2133/2762/2832 anterior a v3.9.8, Vigor 2135/2765/2766 anterior a v4.4.5.1, Vigor 2865/2866/2927 anterior a v4.4.5.3, Vigor 2962/3910 anterior a v4.3.2.7, Vigor 3912 anterior a v4.3.5.2 y Vigor 2925 hasta v3.9.6 permite a los atacantes cargar un módulo de kernel manipulado específicamente, lo que permite la ejecución de código arbitrario.

Un problema en los dispositivos Draytek Vigor 165/166 anteriores a la v4.2.6, Vigor 2620/LTE200 anteriores a la v3.9.8.8, Vigor 2860/2925 anteriores a la v3.9.7, Vigor 2862/2926 anteriores a la v3.9.9.4, Vigor 2133/2762/2832 anteriores a la v3.9.8, Vigor 2135/2765/2766 anteriores a la v4.4.5.1, Vigor 2865/2866/2927 anteriores a la v4.4.5.3, Vigor 2962/3910 anteriores a la v4.3.2.7, Vigor 3912 anteriores a la v4.3.5.2 y Vigor 2925 hasta la v3.9.6 permite a los atacantes cargar aplicaciones manipuladas por ellos. Módulos de cumplimiento que conducen a la ejecución de código arbitrario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/compaction: se corrige la advertencia de cambio fuera de los límites de UBSAN syzkaller informó una advertencia de cambio fuera de los límites de UBSAN de (1UL << order) en isolate_freepages_block(). El compuesto falso puede ser cualquier valor porque es una unión con indicadores. Vuelva a agregar la verificación MAX_PAGE_ORDER para corregir la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hrtimers: fuerza la migración de los hrtimers en cola después de CPUHP_AP_HRTIMERS_DYING. Los hrtimers se migran desde la CPU que se está muriendo a cualquier destino en línea en la etapa CPUHP_AP_HRTIMERS_DYING para no retrasar las tareas de gestión de los temporizadores de ancho de banda involucradas en el progreso de avance de la conexión en caliente de la CPU. Sin embargo, las reactivaciones aún pueden ser realizadas por la CPU saliente después de CPUHP_AP_HRTIMERS_DYING. Esto puede dar como resultado nuevamente que los temporizadores de ancho de banda se activen. Dependiendo de varias consideraciones (elección basada en administración de energía de Crystal Ball, temporizador más antiguo ya en cola, migración de temporizador habilitada o no), el destino puede eventualmente ser la CPU actual incluso si está fuera de línea. Si eso sucede, el temporizador eventualmente se ignora. El ejemplo más notable es RCU, que tuvo que lidiar con todos y cada uno de esos despertares difiriéndolos a una CPU en línea, junto con workarounds relacionados: _ e787644caf76 (rcu: Diferir el despertar de kthreads de RCU cuando la CPU está muriendo) _ 9139f93209d1 (rcu/nocb: Reparar la limitación de RT de hrtimer armado desde una CPU fuera de línea) _ f7345ccc62a4 (rcu/nocb: Reparar el despertar de rcuog desde softirq fuera de línea) El problema no se limita a RCU, ya que el kthread de la máquina de detención (que ejecuta CPUHP_AP_HRTIMERS_DYING) informa su finalización al final de su trabajo a través de cpu_stop_signal_done() y realiza un despertar que eventualmente arma el temporizador del servidor de fecha límite: ADVERTENCIA: CPU: 94 PID: 588 en kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: immigration/94 No contaminado Detenedor: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Rastreo de llamadas: start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread En lugar de proporcionar otro workaround para solucionar la situación, corríjala en la infraestructura de hrtimers: siempre migre un temporizador a un destino en línea cuando se ponga en cola desde una CPU fuera de línea. Esto también permitirá revertir todos los vergonzosos hackeos de RCU mencionados anteriormente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: mark GFP_NOIO around sysfs ->store() sysfs ->store se llama con la cola congelada, mientras tanto tenemos varias devoluciones de llamadas ->store() (update_nr_requests, wbt, scheduler) para asignar memoria con GFP_KERNEL que puede ejecutarse en una ruta de código de recuperación directa, lo que puede provocar un posible bloqueo. Solucione el problema marcando NOIO alrededor de sysfs ->store()

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/xen: se ha corregido xen_hypercall_hvm() para que no bloquee %rbx xen_hypercall_hvm(), que se utiliza cuando se ejecuta como invitado PVH de Xen como máximo una vez durante el arranque inicial, está bloqueando %rbx. Dependiendo de si el autor de la llamada confía en que %rbx se conserve durante la llamada o no, esta obstrucción puede provocar un bloqueo temprano del sistema. Esto se puede evitar utilizando un registro ya guardado en lugar de %rbx.