Vulnerabilidades

Múltiples vulnerabilidades en la interfaz de administración basada en web de los teléfonos IP Cisco Small Business serie SPA300 y los teléfonos IP Cisco Small Business serie SPA500 podrían permitir que un atacante remoto no autenticado ejecute comandos arbitrarios en el sistema operativo subyacente con privilegios de superusuario. Estas vulnerabilidades existen porque los paquetes HTTP entrantes no se verifican adecuadamente en busca de errores, lo que podría provocar un desbordamiento del búfer. Un atacante podría aprovechar esta vulnerabilidad enviando una solicitud HTTP diseñada a un dispositivo afectado. Un exploit exitoso podría permitir al atacante desbordar un búfer interno y ejecutar comandos arbitrarios en el nivel de privilegio superusuario.

Múltiples vulnerabilidades en la interfaz de administración basada en web de los teléfonos IP Cisco Small Business serie SPA300 y los teléfonos IP Cisco Small Business serie SPA500 podrían permitir que un atacante remoto no autenticado provoque que un dispositivo afectado se recargue inesperadamente. Estas vulnerabilidades existen porque los paquetes HTTP no se verifican adecuadamente en busca de errores. Un atacante podría aprovechar esta vulnerabilidad enviando un paquete HTTP manipulado a la interfaz remota de un dispositivo afectado. Un exploit exitoso podría permitir al atacante provocar una condición DoS en el dispositivo.

Múltiples vulnerabilidades en la interfaz de administración basada en web de los teléfonos IP Cisco Small Business serie SPA300 y los teléfonos IP Cisco Small Business serie SPA500 podrían permitir que un atacante remoto no autenticado ejecute comandos arbitrarios en el sistema operativo subyacente con privilegios de superusuario. Estas vulnerabilidades existen porque los paquetes HTTP entrantes no se verifican adecuadamente en busca de errores, lo que podría provocar un desbordamiento del búfer. Un atacante podría aprovechar esta vulnerabilidad enviando una solicitud HTTP manipulada a un dispositivo afectado. Un exploit exitoso podría permitir al atacante desbordar un búfer interno y ejecutar comandos arbitrarios en el nivel de privilegio superusuario.

Una vulnerabilidad en la interfaz de administración basada en web de Cisco ISE podría permitir que un atacante remoto autenticado lleve a cabo un ataque XSS contra un usuario de la interfaz. Esta vulnerabilidad se debe a una validación insuficiente de la entrada proporcionada por el usuario por parte de la interfaz de administración basada en web de un sistema afectado. Un atacante podría aprovechar esta vulnerabilidad inyectando código malicioso en páginas específicas de la interfaz. Un exploit exitoso podría permitir al atacante ejecutar código de script arbitrario en el contexto de la interfaz afectada o acceder a información confidencial basada en el navegador. Para aprovechar esta vulnerabilidad, el atacante debe tener privilegios de administrador en un dispositivo afectado.

Una vulnerabilidad fue encontrada en Tenda i22 1.0.0.3(4687) y clasificada como crítica. Este problema afecta a la función formApPortalOneKeyAuth del archivo /goform/apPortalOneKeyAuth. La manipulación de los datos del argumento provoca un desbordamiento del búfer. El ataque puede iniciarse 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: 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.