Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: manejo de errores de amdgpu_cgs_create_device() en amd_powerplay_create(). Se ha añadido el manejo de errores para propagar los fallos de amdgpu_cgs_create_device() al llamador. Cuando amdgpu_cgs_create_device() falla, se libera hwmgr y se devuelve -ENOMEM para evitar la desreferencia de punteros nulos. [v1]->[v2]: Se ha cambiado el código de error de -EINVAL a -ENOMEM. Se ha liberado hwmgr.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: omapfb: Añadir comprobación del valor "plane". La función dispc_ovl_setup no está diseñada para funcionar con el valor OMAP_DSS_WB del parámetro de enumeración "plane". Este valor se inicializa en dss_init_overlays y, en el estado actual del código, no puede tomar este valor, por lo que no supone un problema real. Para fines de codificación defensiva, no sería superfluo comprobar el valor del parámetro, ya que algunas funciones en la pila de llamadas procesan este valor correctamente y otras no. Por ejemplo, en dispc_ovl_setup_global_alpha, puede provocar un desbordamiento de búfer. Añadir comprobación para este valor. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con la herramienta de análisis estático SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: fprobe events: Fix possible UAF on modules. La confirmación ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module refcount") trasladó try_module_get() de __find_tracepoint_module_cb() al llamador de find_tracepoint(), pero esto introdujo un posible UAF porque el módulo puede descargarse antes que try_module_get(). En este caso, el objeto del módulo también debería liberarse. Por lo tanto, try_module_get() no solo falla, sino que puede acceder al objeto liberado. Para evitarlo, vuelva a intentar try_module_get() en __find_tracepoint_module_cb().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: evitar la desreferencia de puntero nulo en la llamada a dbg. cifs_server_dbg() implica que el servidor no es nulo, por lo que se mueve la llamada bajo condición para evitar la desreferencia de puntero nulo. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pciehp: Evitar comprobaciones innecesarias de reemplazo de dispositivo. La desconexión en caliente de puertos PCI hotplug anidados sufre una condición de ejecución persistente que puede provocar un bloqueo: un puerto hotplug principal adquiere pci_lock_rescan_remove() y espera a que pciehp se desvincule de un puerto hotplug secundario. Mientras tanto, ese puerto hotplug secundario también intenta adquirir pci_lock_rescan_remove() para eliminar sus propios secundarios. El bloqueo solo ocurre si el principal adquiere pci_lock_rescan_remove() primero, no si el secundario lo adquiere primero. A lo largo de los años se han propuesto y descartado varias soluciones alternativas para evitar el problema, por ejemplo: https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/ Se está trabajando en una solución adecuada, pero requiere más tiempo, ya que no es trivial y es necesariamente intrusiva. La reciente confirmación 9d573d19547b ("PCI: pciehp: Detectar reemplazo de dispositivo durante la suspensión del sistema") provoca una mayor frecuencia del bloqueo al eliminar más de un dispositivo Thunderbolt durante la suspensión del sistema. Esta confirmación buscaba detectar el reemplazo del dispositivo, pero también se activó al eliminarlo. Es imposible diferenciar con precisión entre reemplazo y eliminación, ya que pci_get_dsn() devuelve 0 tanto si el dispositivo se eliminó como si se reemplazó por uno sin número de serie del dispositivo. Evite la ocurrencia más frecuente del interbloqueo comprobando si el puerto hotplug se eliminó en caliente. De ser así, no tiene sentido comprobar si su dispositivo secundario se reemplazó. Esto funciona porque la llamada de retorno ->resume_noirq() se invoca de arriba a abajo para toda la jerarquía: un puerto hotplug principal que detecta el reemplazo (o la eliminación) de un dispositivo marca todos los secundarios como eliminados mediante pci_dev_set_disconnected() y un puerto hotplug secundario puede entonces detectar con fiabilidad su eliminación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pwm: mediatek: Evitar la división por cero en pwm_mediatek_config(). Con CONFIG_COMPILE_TEST y !CONFIG_HAVE_CLK, pwm_mediatek_config() presenta una división por cero en la siguiente línea: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm])); debido a que la versión !CONFIG_HAVE_CLK de clk_get_rate() devuelve cero. Se supone que se trata de un problema teórico: COMPILE_TEST anula la dependencia de RALINK, que seleccionaría COMMON_CLK. En cualquier caso, es recomendable comprobar el error explícitamente para evitar la división por cero. Corrige la siguiente advertencia: drivers/pwm/pwm-mediatek.o: advertencia: objtool: .text: final inesperado de sección [ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Desactivación de vGIC al crear una vCPU fallida. Si kvm_arch_vcpu_create() no comparte la página de vCPU con el hipervisor, propagamos el error a ioctl, pero dejamos los datos de vCPU de vGIC inicializados. Cabe destacar que esto solo filtra la memoria correspondiente cuando se destruye la vCPU, sino que también puede provocar un uso después de la liberación si el dispositivo redistribuidor intenta acceder a la vCPU. Agregue la limpieza faltante a kvm_arch_vcpu_create() para garantizar que las estructuras de vCPU de vGIC se destruyan en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: Se corrigen los interbloqueos relacionados con el mantenimiento preventivo en las IOCTL de MS. Se impide la reanudación/suspensión en tiempo de ejecución mientras las IOCTL de MS están en curso. Una suspensión fallida llamará a ivpu_ms_cleanup(), que intentará adquirir file_priv->ms_lock, que ya está en poder de las IOCTL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: Se corrige el bloqueo en ivpu_ms_cleanup(). Se corrige el bloqueo en ivpu_ms_cleanup() impidiendo la reanudación en tiempo de ejecución tras adquirir file_priv->ms_lock. Durante un fallo en la reanudación en tiempo de ejecución, se ejecuta un arranque en frío que llama a ivpu_ms_cleanup_all(). Esta función llama a ivpu_ms_cleanup(), que adquiere file_priv->ms_lock y provoca el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: mops: No desreferenciar el registro src para una operación set. El registro fuente no se utiliza para SET* y leerlo puede resultar en un error de acceso a la matriz UBSAN fuera de los límites, específicamente cuando la excepción MOPS se toma de una secuencia SET* con XZR (reg 31) como origen. Arquitectónicamente, este es el único caso donde un campo src/dst/size en el ESR puede reportarse como 31. Antes de 2de451a329cf662b, el código en do_el0_mops() era benigno ya que el uso de pt_regs_read_reg() impedía el acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Corregir el desequilibrio en el recuento de referencias de netns que causa fugas y uso después de la liberación. La confirmación ef7134c7fc48 ("smb: cliente: Corregir el uso después de la liberación del espacio de nombres de red") intentó corregir un problema de uso después de la liberación de netns ajustando manualmente los recuentos de referencias mediante sk->sk_net_refcnt y sock_inuse_add(). Sin embargo, una confirmación posterior e9f2517a3e18 ("smb: cliente: Corregir el bloqueo de los temporizadores TCP después de rmmod") indicó que la configuración manual de sk->sk_net_refcnt en la primera confirmación era técnicamente incorrecta, ya que sk->sk_net_refcnt solo debe configurarse para sockets de usuario. Esto provocó problemas como que los temporizadores TCP no se borraran correctamente al cerrar. La segunda confirmación se adaptó a un modelo que simplemente almacena una referencia netns adicional para server->ssocket mediante get_net() y la elimina al desmantelar el servidor. Sin embargo, persisten algunas deficiencias en el equilibrio entre get_net() y put_net(), añadidas por estas confirmaciones. El manejo incompleto de las referencias en estas correcciones genera dos problemas: 1. Fugas de recuento de referencias de netns[1]. El proceso del problema es el siguiente: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* Primero, obtener net. */ ip_connect generic_ip_connect /* Intentar el puerto 445 */ get_net() ->connect() /* Error */ put_net() generic_ip_connect /* Intentar el puerto 139 */ get_net() /* Falta put_net() coincidente para este get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release(); server->ssocket = NULL; /* Falta put_net() aquí. */ generic_ip_connect get_net() ->connect() /* Error */ put_net() sock_release(); server->ssocket = NULL; free_rsp_buf ... clean_demultiplex_info /* Solo se llama una vez aquí. */ put_net() ``` Cuando se activa cifs_reconnect(), el servidor->ssocket se libera sin un put_net() correspondiente para la referencia obtenida previamente en generic_ip_connect(). Termina llamando a generic_ip_connect() de nuevo para reintentar get_net(). Después, el servidor->ssocket se establece en NULL en la ruta de error de generic_ip_connect(), y el recuento neto no se puede liberar en la función clean_demultiplex_info() final. 2. Posible uso después de la liberación. El esquema actual de recuento de referencias puede generar un posible problema de uso después de la liberación en el siguiente escenario: ``` cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net */ ip_connect generic_ip_connect get_net() bind_socket kernel_bind /* failed */ put_net() /* after out_err_crypto_release label */ put_net() /* after out_err label */ put_net() ``` En el proceso de gestión de excepciones donde falla la vinculación del socket, las llamadas get_net() y put_net() están desequilibradas, lo que puede provocar que el recuento de referencias server->net baje a cero y se libere prematuramente. Para solucionar ambos problemas, este parche vincula el recuento de referencias netns ---truncated---

El complemento IMITHEMES Listing es vulnerable a la escalada de privilegios mediante la apropiación de cuentas en todas las versiones hasta la 3.3 incluida. Esto se debe a que el complemento no valida correctamente el valor del código de verificación antes de actualizar la contraseña mediante la función imic_reset_password_init(). Esto permite que atacantes no autenticados cambien la contraseña de cualquier usuario, incluyendo la de administradores, si se conoce su correo electrónico.