Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: limpieza del manejo de errores en vpci_scan_bus() Smatch se queja de una verificación NULL inconsistente en vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c :1024 Error de vpci_scan_bus(): anteriormente asumimos que 'vpci_bus' podría ser nulo (consulte la línea 1021). En lugar de imprimir un mensaje de error y luego fallar, deberíamos devolver un código de error y limpiar. Además, la verificación NULL se invierte, por lo que imprime un error de éxito en lugar de fracaso.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: PCI: rcar: Degradar WARN() a dev_warn_ratelimited() en rcar_pcie_wakeup() Evitar un gran backtrace, basta con avisar al usuario que ha habido un problema de enlace. O el enlace falló y el sistema necesita mantenimiento, o el enlace continúa funcionando y el usuario ha sido informado. El mensaje de la advertencia se puede buscar en las fuentes. Esto hace que un problema de enlace real sea menos detallado. En primer lugar, este controlador tiene una limitación en el sentido de que el controlador del controlador tiene que ayudar al hardware con la transición al estado de enlace L1 escribiendo L1IATN en el registro PMCTRL; el cambio de estado de enlace L1 y L0 no es completamente automático en este controlador. En el caso de un controlador ASMedia ASM1062 PCIe SATA que no admite ASPM, al entrar a suspender o durante la plataforma pm_test, el controlador SATA ingresa al estado D3hot y el enlace ingresa al estado L1. Si el controlador SATA se activa antes de que se llamara a rcar_pcie_wakeup() y regresa a D0, el enlace regresa a L0 antes de que el controlador del controlador comenzara su transición al estado de enlace L1. En este punto, el controlador SATA envió un DLLP PM_ENTER_L1 al controlador PCIe y el controlador PCIe lo recibió, y el controlador PCIe configuró el bit PMSR PMEL1RX. Una vez que se llama a rcar_pcie_wakeup(), si el enlace ya está nuevamente en el estado L0 y el bit PMEL1RX está configurado, el controlador del controlador no tiene forma de determinar si debe realizar la transición del enlace al estado L1 o tratar el enlace como si estuviera en estado L0. Estado L0. Actualmente, el controlador intenta realizar la transición al estado del enlace L1 incondicionalmente, lo que en este caso específico falla con un tiempo de espera de sondeo PMSR L1FAEG; sin embargo, el enlace aún funciona porque ya está nuevamente en el estado L0. Reduzca la verbosidad de esta advertencia. En caso de que el enlace esté realmente roto, rcar_pcie_config_access() fallará; de lo contrario, tendrá éxito y cualquier sistema con este controlador y ASM1062 puede suspenderse sin generar un seguimiento.

Se encontró una vulnerabilidad en Genexis Tilgin Home Gateway 322_AS0500-03_05_13_05. Ha sido calificada como problemática. Este problema afecta un procesamiento desconocido del archivo /vood/cgi-bin/vood_view.cgi?lang=EN&act=user/spec_conf&sessionId=86213915328111654515&user=A&message2user=Account%20updated. La manipulación del argumento Número de teléfono conduce a cross-site scripting. 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.

Una vulnerabilidad ha sido encontrada en chillzhuang SpringBlade 4.1.0 y clasificada como crítica. Una función desconocida del archivo /api/blade-system/menu/list?updatexml es afectada por esta vulnerabilidad. La manipulación conduce a la inyección de SQL. Es posible lanzar el ataque 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 resolvió la siguiente vulnerabilidad: net/mlx5: siempre drena el estado al apagar la devolución de llamada. No tiene sentido la recuperación durante el apagado del dispositivo. si comenzó el trabajo de salud, debe esperar para evitar ejecuciones y acceso al puntero NULL. Por lo tanto, drene el WQ de salud al cerrar la devolución de llamada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: prime: corrige el desbordamiento insuficiente de refcount Llamar a nouveau_bo_ref() en un nouveau_bo sin inicializarlo (y por lo tanto el ttm_bo de respaldo) conduce a un desbordamiento insuficiente de refcount. En lugar de llamar a nouveau_bo_ref() en la ruta de desenredado de drm_gem_object_init(), limpie las cosas manualmente. (cereza escogida del commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv/purgatory: align riscv_kernel_entry Cuando el manejo de la alineación se delega al kernel, todo debe estar alineado por palabras en el purgatorio, ya que el controlador de trampas se establece en kexec. Sin la alineación, alcanzar la excepción finalmente fallaría. En otras ocasiones, el controlador del kernel se encargaría de las excepciones. Esto se probó en un SoC JH7110 con oreboot y su SBI que delegaba excepciones de acceso no alineadas y el kernel configurado para manejarlas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wan: fsl_qmc_hdlc: convierte el spinlock de Carrier_lock en un mutex El spinlock de Carrier_lock protege la detección del operador. Mientras se mantiene, se llama a framer_get_status(), que a su vez toma un mutex. Esto no es correcto y puede llevar a un punto muerto. Una ejecución con PROVE_LOCKING habilitado detectó el problema: [ERROR: Contexto de espera no válido] ... c204ddbc (&framer->mutex){+.+.}-{3:3}, en: framer_get_status+0x40/0x78 otra información que podría ayúdenos a depurar esto: contexto-{4:4} 2 bloqueos retenidos por ifconfig/146: #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, en: devinet_ioctl+0x12c/0x664 #1: c2006a40 (&qmc_hdlc->carrier_lock){....}-{2:2}, en: qmc_hdlc_framer_set_carrier+0x30/0x98 Evite el uso de spinlock y convierta carrier_lock en un mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: corrige las fugas de actualización de la entrada CT del contexto del encabezado de modificación. El commit citada asigna un nuevo encabezado de modificación para reemplazar el anterior al actualizar la entrada CT. Pero si no se pudo asignar uno nuevo, por ejemplo. Si excede el número máximo que el firmware puede admitir, modificar el encabezado será un indicador de error que provocará pánico al desasignarlo. Y el punto de encabezado de modificación anterior se copia al atributo anterior. Cuando se libera el antiguo atributo, el antiguo encabezado de modificación se pierde. Solucionelo restaurando el antiguo atributo a attr cuando no se pudo asignar un nuevo contexto de encabezado de modificación. Entonces, cuando se libera la entrada CT, se liberará el contexto del encabezado de modificación derecho. Y el pánico al acceder al puntero de error también se soluciona.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/fpu: volver a agregar el manejo de excepciones en load_fpu_state() Con la reciente reescritura del código fpu, el manejo de excepciones para la instrucción lfpc dentro de load_fpu_state() se eliminó erróneamente. Agréguelo nuevamente para evitar que la carga de valores de registro de coma flotante no válidos provoque una excepción de especificación no controlada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vmwgfx: soluciona un punto muerto en el sondeo de valla de dma buf. Introduce una versión de las operaciones de valla que, al lanzarse, no elimina la valla de la lista de pendientes y, por tanto, no requiere un bloqueo para arreglar los puntos muertos de encuesta->espera de valla->cerca sin referencia. vmwgfx sobrescribe la devolución de llamada de espera para iterar sobre la lista de todas las barreras y actualizar su estado; para ello, mantiene un bloqueo para evitar que otros subprocesos modifiquen la lista. La devolución de llamada de destrucción de valla elimina la valla y la elimina de la lista de vallas pendientes, para las cuales mantiene un bloqueo. dma buf polling cb desrefs una valla después de haber sido señalada: entonces la encuesta llama a la espera, lo que señala las vallas que están siendo destruidas. La destrucción intenta adquirir el bloqueo en la lista de vallas pendientes que nunca puede conseguir porque está retenido por la espera desde la que fue llamado. Error antiguo, pero no muchas aplicaciones de espacio de usuario usaban interfaces de sondeo dma-buf. Solucionarlos, en particular esto soluciona los bloqueos/bloqueos de KDE.

** NO COMPATIBLE CUANDO SE ASIGNÓ ** El componente Apache Helix Front (UI) contenía un secreto codificado que permitía a un atacante falsificar sesiones generando sus propias cookies falsas. Este problema afecta a Apache Helix Front (UI): todas las versiones. Como este proyecto está retirado, no planeamos lanzar una versión que solucione este problema. Se recomienda a los usuarios que busquen una alternativa o restrinjan el acceso a la instancia a usuarios confiables. NOTA: Esta vulnerabilidad solo afecta a productos que ya no son compatibles con el fabricante.