Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: sdhci: Corrección max_seg_size para 64KiB PAGE_SIZE blk_queue_max_segment_size() asegurado: if (max_size < PAGE_SIZE) max_size = PAGE_SIZE; mientras que: blk_validate_limits() lo convierte en un error: if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE)) return -EINVAL; El cambio de uno a otro expuso a sdhci, que estaba estableciendo un tamaño de segmento máximo demasiado bajo en algunas circunstancias. Fije el tamaño máximo del segmento cuando sea demasiado bajo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/filemap: hacer que MAX_PAGECACHE_ORDER sea aceptable para xarray Serie de parches "mm/filemap: limitar el tamaño de caché de página al admitido por xarray", v2. Actualmente, xarray no puede admitir un tamaño de caché de página arbitrario. Se pueden encontrar más detalles en la declaración WARN_ON() en xas_split_alloc(). En nuestra prueba cuyo código se adjunta a continuación, presionamos WARN_ON() en el sistema ARM64 donde el tamaño de página base es de 64 KB y el tamaño de página enorme es de 512 MB. El problema se informó hace mucho tiempo y se pueden encontrar algunas discusiones al respecto aquí [1]. [1] https://www.spinics.net/lists/linux-xfs/msg75404.html Para solucionar el problema, debemos ajustar MAX_PAGECACHE_ORDER a uno compatible con xarray y evitar el caché de páginas del tamaño de PMD si es necesario. Los cambios de código los sugiere David Hildenbrand. PATCH[1] ajusta MAX_PAGECACHE_ORDER al soportado por xarray PATCH[2-3] evita el caché de páginas de tamaño PMD en la ruta de lectura anticipada sincrónica PATCH[4] evita el caché de páginas de tamaño PMD para archivos shmem si es necesario Programa de prueba ===== ======= # cat test.c #define _GNU_SOURCE #incluye #incluye #incluye #incluye #incluye #include #include #include #define TEST_XFS_FILENAME "/tmp/data" #define TEST_SHMEM_FILENAME "/dev/shm/data" #define TEST_MEM_SIZE 0x20000000 int main(int argc, char **argv) { const char *nombre de archivo; intfd = 0; vacío *buf = (vacío *)-1, *p; int pgsize = getpagesize(); ret int; if (pgsize != 0x10000) { fprintf(stderr, "se requiere un tamaño de página base de 64 KB\n"); devolver -EPERM; } system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled"); sistema("rm -fr /tmp/data"); sistema("rm -fr /dev/shm/data"); sistema("echo 1 > /proc/sys/vm/drop_caches"); /* Abrir archivo xfs o shmem */ filename = TEST_XFS_FILENAME; if (argc > 1 && !strcmp(argv[1], "shmem")) nombre de archivo = TEST_SHMEM_FILENAME; fd = open(nombre de archivo, O_CREAT | O_RDWR | O_TRUNC); if (fd < 0) { fprintf(stderr, "No se puede abrir <%s>\n", nombre de archivo); devolver -EIO; } /* Ampliar tamaño de archivo */ ret = ftruncate(fd, TEST_MEM_SIZE); if (ret) { fprintf(stderr, "Error %d al ftruncate()\n", ret); ir a limpieza; } /* Crear VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (buf == (void *)-1) { fprintf(stderr, "No se puede mmap <%s>\n", nombre de archivo); ir a limpieza; } fprintf(stdout, "búfer asignado en 0x%p\n", buf); ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); if (ret) { fprintf(stderr, "No se puede madvise(MADV_HUGEPAGE)\n"); ir a limpieza; } /* Completar VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE); if (ret) { fprintf(stderr, "Error %d en madvise(MADV_POPULATE_WRITE)\n", ret); ir a limpieza; } /* Perfora el archivo para aplicar la división xarray */ ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - pgsize, pgsize); if (ret) fprintf(stderr, "Error %d al fallacate()\n", ret); limpieza: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); si (fd > 0) cerrar(fd); devolver 0; } # gcc test.c -o prueba # cat /proc/1/smaps | grep Tamaño de página de kernel | head -n 1 KernelPageSize: 64 kB # ./test shmem : ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 17 PID: 5253 en lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Módulos vinculados en: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon \ drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ virtio_net sha1_ce net_failover failover virtio_console virtio_blk \ dimlib virtio_mmio CPU: 17 PID: 5253 Comm: prueba Kdump: cargado Contaminado: GW 6.10.0-rc5-gavin+ #12 ---truncado---

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().

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.