Vulnerabilidades

Se descubrió que RELY-PCIe v22.2.1 a v23.1.0 contenía una vulnerabilidad de inyección de comandos a través de la función sys_mgmt.

Una vulnerabilidad en el manejo de tramas Ethernet específicas por parte del software Cisco IOS XR para varias plataformas Cisco Network Convergence System (NCS) podría permitir que un atacante adyacente no autenticado provoque que se descarten paquetes de prioridad crítica, lo que da como resultado una condición de denegación de servicio (DoS). Esta vulnerabilidad se debe a la clasificación incorrecta de ciertos tipos de tramas Ethernet que se reciben en una interfaz. Un atacante podría aprovechar esta vulnerabilidad enviando tipos específicos de tramas Ethernet al dispositivo afectado o a través de él. Una explotación exitosa podría permitir que el atacante provoque que las relaciones de protocolo del plano de control fallen, lo que da como resultado una condición de denegación de servicio. Para obtener más información, consulte la sección de este aviso. Cisco ha publicado actualizaciones de software que solucionan esta vulnerabilidad. No existen workarounds que solucionen esta vulnerabilidad.

Una vulnerabilidad en la CLI del software Cisco IOS XR podría permitir que un atacante local autenticado lea cualquier archivo en el sistema de archivos del sistema operativo Linux subyacente. El atacante debe tener credenciales válidas en el dispositivo afectado. Esta vulnerabilidad se debe a una validación incorrecta de los argumentos que se pasan a un comando CLI específico. Un atacante podría aprovechar esta vulnerabilidad iniciando sesión en un dispositivo afectado con credenciales con pocos privilegios y utilizando el comando afectado. Una explotación exitosa podría permitir que el atacante acceda a archivos en modo de solo lectura en el sistema de archivos Linux.

Una vulnerabilidad en la función API JSON-RPC en ConfD que utilizan las interfaces de administración basadas en web de Cisco Crosswork Network Services Orchestrator (NSO), Cisco Optical Site Manager y Cisco RV340 Dual WAN Gigabit VPN Routers podría permitir que un atacante remoto autenticado modifique la configuración de una aplicación o dispositivo afectado. Esta vulnerabilidad se debe a comprobaciones de autorización incorrectas en la API. Un atacante con privilegios suficientes para acceder a la aplicación o dispositivo afectado podría explotar esta vulnerabilidad enviando solicitudes maliciosas a la API JSON-RPC. Una explotación exitosa podría permitir al atacante realizar modificaciones no autorizadas a la configuración de la aplicación o dispositivo afectado, incluida la creación de nuevas cuentas de usuario o la elevación de sus propios privilegios en un sistema afectado.

Una vulnerabilidad en la función Dedicated XML Agent del software Cisco IOS XR podría permitir que un atacante remoto no autenticado provoque una denegación de servicio (DoS) en el puerto de escucha XML TCP 38751. Esta vulnerabilidad se debe a la falta de una validación de errores adecuada de los paquetes XML de entrada. Un atacante podría aprovechar esta vulnerabilidad enviando un flujo continuo y elaborado de tráfico XML a un dispositivo de destino. Una explotación exitosa podría permitir al atacante hacer que el puerto XML TCP 38751 se vuelva inaccesible mientras persista el tráfico de ataque.

Una vulnerabilidad en la CLI del software Cisco IOS XR podría permitir que un atacante local autenticado obtenga acceso de lectura y escritura al sistema de archivos en el sistema operativo subyacente de un dispositivo afectado. Esta vulnerabilidad se debe a una validación insuficiente de los argumentos de usuario que se pasan a comandos CLI específicos. Un atacante con una cuenta con pocos privilegios podría aprovechar esta vulnerabilidad mediante el uso de comandos manipulados en el indicador. Una explotación exitosa podría permitir al atacante elevar los privilegios a superusuario.

Una vulnerabilidad en la función multicast traceroute versión 2 (Mtrace2) del software Cisco IOS XR podría permitir que un atacante remoto no autenticado agote la memoria de paquetes UDP de un dispositivo afectado. Esta vulnerabilidad existe porque el código Mtrace2 no maneja correctamente la memoria de paquetes. Un atacante podría aprovechar esta vulnerabilidad enviando paquetes manipulados a un dispositivo afectado. Una explotación exitosa podría permitir que el atacante agote la memoria de paquetes UDP entrantes. El dispositivo afectado no podría procesar paquetes de protocolos basados en UDP de nivel superior, lo que posiblemente provoque una condición de denegación de servicio (DoS). Nota: Esta vulnerabilidad se puede aprovechar utilizando IPv4 o IPv6.

El controlador de impresión universal de Samsung para Windows es potencialmente vulnerable a la escalada de privilegios, lo que permite la creación de un shell inverso en la herramienta. Esto solo se aplica a los productos de la aplicación lanzados o fabricados antes de 2018.

Vulnerabilidad de redirección de URL a un sitio no confiable ('Redirección abierta') en Payara Platform Payara Server (módulos de interfaz de administración REST) permite el secuestro de sesión. Este problema afecta a Payara Server: desde 6.0.0 antes de 6.18.0, desde 6.2022.1 antes de 6.2024.9, desde 5.2020.2 antes de 5.2022.5, desde 5.20.0 antes de 5.67.0, desde 4.1.2.191.0 antes de 4.1.2.191.50.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige un fallo del verificador del kernel en stacksafe() Daniel Hodges informó de un fallo del verificador del kernel al jugar con sched-ext. Una investigación más profunda muestra que el fallo se debe a un acceso a memoria no válido en stacksafe(). Más específicamente, es el siguiente código: if (exact != NOT_EXACT && old->stack[spi].slot_type[i % BPF_REG_SIZE] != cur->stack[spi].slot_type[i % BPF_REG_SIZE]) return false; La 'i' itera old->allocated_stack. Si cur->allocated_stack < old->allocated_stack, se producirá el acceso fuera de límites. Para solucionar el problema, agregue la comprobación 'i >= cur->allocated_stack' de modo que, si la condición es verdadera, stacksafe() debería fallar. De lo contrario, el acceso a la memoria cur->stack[spi].slot_type[i % BPF_REG_SIZE] es legal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/raid1: Reparar la corrupción de datos para la matriz degradada con disco lento read_balance() evitará la lectura de discos lentos tanto como sea posible, sin embargo, si los datos válidos solo llegan a discos lentos, y un nuevo disco normal aún está en recuperación, se pueden leer los datos no recuperados: raid1_read_request read_balance raid1_should_read_first -> return false choose_best_rdev -> no se recupera el disco normal, devuelve -1 choose_bb_rdev -> falta la comprobación de recuperación, devuelve el disco normal -> leer datos no recuperados La causa raíz es que falta la comprobación de recuperación en choose_bb_rdev(). Por lo tanto, agregue dicha comprobación para solucionar el problema. También solucione un problema similar en choose_slow_rdev().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrección del bloqueo de PT de hugetlb frente a core-mm Recientemente hicimos que el código de recorrido de tabla de páginas común de GUP también recorriera VMA hugetlb sin la mayoría de las mayúsculas y minúsculas especiales de hugetlb, preparándonos para el futuro de tener menos código de recorrido de tabla de páginas específico de hugetlb en la base de código. Resulta que nos perdimos un detalle de bloqueo de tabla de páginas: el bloqueo de tabla de páginas para folios hugetlb que no están mapeados usando un solo PMD/PUD. Supongamos que tenemos un folio hugetlb que abarca múltiples PTE (por ejemplo, folios hugetlb de 64 KiB en arm64 con un tamaño de página base de 4 KiB). GUP, mientras recorre las tablas de páginas, realizará un pte_offset_map_lock() para agarrar el bloqueo de tabla PTE. Sin embargo, hugetlb que modifica simultáneamente estas tablas de páginas en realidad agarraría el mm->page_table_lock: con USE_SPLIT_PTE_PTLOCKS, los bloqueos serían diferentes. Algo similar puede suceder ahora mismo con folios hugetlb que abarcan múltiples PMD cuando USE_SPLIT_PMD_PTLOCKS. Este problema se puede reproducir [1], por ejemplo, activando: [ 3105.936100] ------------[ cortar aquí ]------------ [ 3105.939323] ADVERTENCIA: CPU: 31 PID: 2732 en mm/gup.c:142 try_grab_folio+0x11c/0x188 [ 3105.944634] Módulos vinculados en: [...] [ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer No contaminado 6.10.0-64.eln141.aarch64 #1 [ 3105.980406] Nombre del hardware: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 24/05/2024 [ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3105.991108] pc : try_grab_folio+0x11c/0x188 [ 3105.994013] lr : follow_page_pte+0xd8/0x430 [ 3105.996986] sp : ffff80008eafb8f0 [ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43 [ 3106.004414] x26: 0000000000000001 x25: 00000000000000000 x24: ffff80008eafba48 [ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978 [ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001 [ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffffff x15: 0000000000000000 [ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000 [ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9: ffffb854771b12f0 [ 3106.034324] x8: 000800000000000 x7: ffff7a546c1aa980 x6: 0008000000000080 [ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000 [ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000 [ 3106.047957] Rastreo de llamadas: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598 Hagamos que huge_pte_lockptr() use efectivamente los mismos bloqueos PT que cualquier rastreador de tablas de páginas core-mm haría. Agregue ptep_lockptr() para obtener el bloqueo de la tabla de páginas PTE usando un puntero pte - desafortunadamente no podemos convertir pte_lockptr() porque virt_to_page() no funciona con tablas de páginas kmap'ed que podemos tener con CONFIG_HIGHPTE. Maneje CONFIG_PGTABLE_LEVELS correctamente verificando en orden inverso, de modo que cuando, por ejemplo, CONFIG_PGTABLE_LEVELS==2 con PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE funcionará como se espera. Documente por qué funciona eso. Hay un caso desagradable: powerpc 8xx, en el que tenemos un folio hugetlb de 8 MiB que se asigna utilizando dos tablas de páginas PTE. Mientras hugetlb quiere tomar el bloqueo de la tabla PMD, core-mm tomaría el bloqueo de la tabla PTE de una de ambas tablas de páginas PTE. En tales casos extremos, tenemos que asegurarnos de que ambos bloqueos coincidan, lo que (¡afortunadamente!) --- truncado ----