Vulnerabilidades

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: tty: serial: ma35d1: agregue una verificación NULL para of_node El pdev->dev.of_node puede ser NULL si el nodo "serial" está ausente. Agregue una verificación NULL para devolver un error en tales casos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: no desoptimizar el mensaje en spi_async() Llamar a spi_maybe_unoptimize_message() en spi_async() es incorrecto porque es probable que el mensaje esté en la cola y aún no se haya transferido. Esto puede dañar el mensaje mientras lo utiliza el controlador del controlador. spi_maybe_unoptimize_message() ya se llama en el lugar correcto en spi_finalize_current_message() para equilibrar la llamada a spi_maybe_optimize_message() en spi_async().

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.

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.