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.

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: libceph: corrige la ejecución entre retardado_work() y ceph_monc_stop() La forma en que se maneja el trabajo retrasado en ceph_monc_stop() es propensa a ejecucións con mon_fault() y posiblemente también con Finish_hunting(). Ambos pueden volver a poner en cola el trabajo retrasado que no sería cancelado por ninguno de los siguientes códigos en caso de que eso suceda después de que se ejecute cancel_delayed_work_sync() - __close_session() no interfiere con el trabajo retrasado para evitar interferir con la búsqueda lógica de intervalo. Esta parte se omitió en el commit b5d91704f53e ("libceph: comportarse en mon_fault() si cur_mon < 0") y el use-after-free aún puede producirse en monc y los objetos que cuelgan de él, con monc->auth y monc-> monmap es particularmente susceptible de ser reutilizado rápidamente. Para solucionar esto: - borre monc->cur_mon y monc->hunting como parte del cierre de la sesión en ceph_monc_stop() - libere de delay_work() si monc->cur_mon está borrado, similar a como se hace en mon_fault() y Finish_hunting () (basado en monc->hunting): llame a cancel_delayed_work_sync() después de cerrar la sesión

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: usb: gadget: configfs: Evitar lectura/escritura OOB en usb_string_copy() Las cadenas 's' proporcionadas por el espacio de usuario podrían tener trivialmente una longitud cero. Si no se marca, esto dará como resultado en primer lugar una lectura OOB en el formato `if (str[0 - 1] == '\n') seguida de cerca por una escritura OOB en el formato `str[0 - 1] = '\0' `. Ya existe una verificación de validación para detectar cadenas que son demasiado largas. Proporcionemos una verificación adicional para cadenas no válidas que sean demasiado cortas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: firmware: cs_dsp: Validar la longitud de el payload antes de procesar el bloque. Mueva la verificación de la longitud de el payload en cs_dsp_load() y cs_dsp_coeff_load() para que se realice antes de que se procese el bloque. La verificación de que la longitud de el payload de un bloque no exceda el número de bytes restantes en el búfer del archivo de firmware se estaba realizando cerca del final de la iteración del bucle. Sin embargo, algún código anterior a esa verificación usaba el campo de longitud sin validarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Devuelve error si el encabezado del bloque desborda el archivo devuelve un error de cs_dsp_power_up() si el encabezado de un bloque es más largo que la cantidad de datos que quedan en el archivo. El código anterior en cs_dsp_load() y cs_dsp_load_coeff() se repetiría mientras quedaran suficientes datos en el archivo para una región válida. Esto protegía contra la sobrecarga del final de los datos del archivo, pero no cancelaba el procesamiento del archivo con un error.

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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/bhi: evitar advertencia en el controlador #DB debido a la mitigación de BHI Cuando la mitigación de BHI está habilitada, si se invoca SYSENTER con el indicador TF configurado, entonces Entry_SYSENTER_compat() usa CLEAR_BRANCH_HISTORY y llama al clear_bhb_loop() antes de que se borre la bandera TF. Esto hace que el controlador #DB (exc_debug_kernel()) emita una advertencia porque se utiliza un solo paso fuera de la función Entry_SYSENTER_compat(). Para solucionar este problema, Entry_SYSENTER_compat() debe usar CLEAR_BRANCH_HISTORY después de asegurarse de que el indicador TF esté borrado. El problema se puede reproducir con la siguiente secuencia: $ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); } $ gcc -o sysenter_step sysenter_step.c $ ./sysenter_step Fallo de segmentación (núcleo volcado) Se espera que el programa falle y el controlador #DB emitirá una advertencia. Registro del kernel: ADVERTENCIA: CPU: 27 PID: 7000 en arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160... RIP: 0010:exc_debug_kernel+0xd2/0x160... Seguimiento de llamadas: <#DB> ? show_regs+0x68/0x80? __advertir+0x8c/0x140 ? exc_debug_kernel+0xd2/0x160? report_bug+0x175/0x1a0? handle_bug+0x44/0x90? exc_invalid_op+0x1c/0x70? asm_exc_invalid_op+0x1f/0x30? exc_debug_kernel+0xd2/0x160 exc_debug+0x43/0x50 asm_exc_debug+0x1e/0x40 RIP: 0010:clear_bhb_loop+0x0/0xb0 ... ? Entry_SYSENTER_compat_after_hwframe+0x6e/0x8d [bp: mensaje de commit de masaje. ]