Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/pci: Se ha corregido un error pci_dev_put() duplicado en disabled_slot() cuando un PF tiene VFs secundarios. Con el commit bcb5d6c76903 ("s390/pci: introducir un bloqueo para sincronizar el estado de zpci_dev"), el código para ignorar el apagado de un PF con VFs secundarios se cambió de un retorno directo a un goto a la sección de desbloqueo y pci_dev_put(). Sin embargo, el cambio dejó intacto el pci_dev_put() existente, lo que resultó en un doble put. Esto puede provocar un use after free si la estructura pci_dev se libera en un estado inesperado. Se soluciona eliminando el pci_dev_put() adicional.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Se corrige la obtención de entrada no válida en ath12k_dp_mon_srng_process Actualmente, ath12k_dp_mon_srng_process usa ath12k_hal_srng_src_get_next_entry para obtener la siguiente entrada del anillo de destino. Esto es incorrecto porque ath12k_hal_srng_src_get_next_entry está diseñado para anillos de origen, no de destino. Esto conduce a la obtención de entradas no válidas, lo que puede causar corrupción de datos o bloqueos debido al acceso a ubicaciones de memoria incorrectas. Esto sucede porque el anillo de origen y el anillo de destino tienen diferentes mecanismos de manejo y el uso de la función incorrecta da como resultado una aritmética de punteros y una gestión del anillo incorrectas. Para solucionar este problema, reemplace la llamada a ath12k_hal_srng_src_get_next_entry por ath12k_hal_srng_dst_get_next_entry en ath12k_dp_mon_srng_process. Esto garantiza que se utilice la función correcta para obtener entradas del anillo de destino, evitando accesos no válidos a la memoria. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1. Probado en: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Se ha corregido el acceso no válido a datos en ath12k_dp_rx_h_undecap_nwifi. En ciertos casos, el hardware podría proporcionar paquetes con una longitud superior a la longitud máxima del encabezado Wi-Fi nativo. Esto puede provocar el acceso y la modificación de campos del encabezado dentro de la función ath12k_dp_rx_h_undecap_nwifi para el tipo de decap DP_RX_DECAP_TYPE_NATIVE_WIFI, lo que podría provocar acceso no válido a datos y corrupción de memoria. Se ha añadido una comprobación de seguridad antes de procesar el SKB para evitar el acceso no válido a datos en la función Wi-Fi nativa undecap para el tipo de decap DP_RX_DECAP_TYPE_NATIVE_WIFI. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xenbus: Usar kref para rastrear el tiempo de vida de req. Marek informó haber visto un fallo de puntero nulo en la pila de llamadas xenbus_thread: ERROR: desreferencia de puntero nulo del kernel, dirección: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Rastreo de llamadas: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 process_msg+0x18e es req->cb(req). req->cb está configurado como xs_wake_up(), una envoltura ligera alrededor de wake_up(), o xenbus_dev_queue_reply(). Parece que en este caso era xs_wake_up(). Parece que req pudo haber despertado xs_wait_for_reply(), que liberó la solicitud. Cuando xenbus_thread se reanuda, falla en los datos con ceros. La segunda edición de los controladores de dispositivos de Linux indica: «Normalmente, una llamada wake_up puede provocar una reprogramación inmediata, lo que significa que otros procesos podrían ejecutarse antes de que wake_up regrese». ... lo cual coincidiría con el comportamiento observado. Se recomienda mantener dos krefs en cada solicitud: uno para el que realiza la llamada y otro para xenbus_thread. Cada uno ejecutará kref_put() al finalizar, y el último lo liberará. Este uso de kref coincide con la descripción en Documentation/core-api/kref.rst.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: bpf: Añadir mitigación de BHB al epílogo de programas cBPF. Un programa BPF malicioso puede manipular el historial de ramificaciones para influir en lo que el hardware especula que ocurrirá a continuación. Al salir de un programa BPF, se emite la secuencia de mitigación de BHB. Esto solo se aplica a programas cBPF clásicos cargados por seccomp.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: impide escrituras de flujo fuera de los límites mediante la validación de *pos. ksmbd_vfs_stream_write() no validaba si el desplazamiento de escritura (*pos) estaba dentro de los límites de la longitud de datos del flujo existente (v_len). Si *pos era mayor o igual que v_len, esto podía provocar una escritura en memoria fuera de los límites. Este parche añade una comprobación para garantizar que *pos sea menor que v_len antes de continuar. Si la condición falla, se devuelve -EINVAL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: permite que las operaciones PM del bus MDIO inicien o detengan la máquina de estados para PHY controlada por phylink DSA tiene 2 tipos de controladores: 1. Los que llaman a dsa_switch_suspend() y dsa_switch_resume() desde las operaciones PM de su dispositivo: qca8k-8xxx, bcm_sf2, microchip ksz 2. Los que no lo hacen: todos los demás. Los métodos anteriores deberían ser opcionales. Para el tipo 1, dsa_switch_suspend() llama a dsa_user_suspend() -> phylink_stop() y dsa_switch_resume() llama a dsa_user_resume() -> phylink_start(). Estos parecen buenos candidatos para establecer mac_managed_pm = true porque esa es esencialmente su definición [1], pero ese no parece ser el mayor problema por ahora y no es en lo que se centra este cambio. Hablando estrictamente sobre la segunda categoría de controladores DSA (que no tienen PM administrado por MAC, lo que significa que para sus PHYs conectados, mdio_bus_phy_suspend() y mdio_bus_phy_resume() deben ejecutarse por completo), he notado que se activa la siguiente advertencia de mdio_bus_phy_resume(): WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP); porque la máquina de estados PHY está en ejecución. Se está ejecutando como resultado de un dsa_user_open() -> ... -> phylink_start() -> phy_start() previo iniciado por el usuario. El mdio_bus_phy_suspend() anterior debería haber llamado a phy_stop_machine(), pero no lo hizo. Por eso, el PHY está en estado PHY_NOLINK cuando se ejecuta mdio_bus_phy_resume(). mdio_bus_phy_suspend() no llamó a phy_stop_machine() porque, para phylink, el puntero a la función phydev->adjust_link es NULL. Esto parece ser un tecnicismo introducido por el commit fddd91016d16 ("phylib: corrección del reinicio de la máquina de estados PAL al reanudar"). Esta confirmación se escribió antes de que existiera phylink y su objetivo era evitar fallos con controladores de consumidor que no utilizan la máquina de estados PHY; phylink siempre lo hace al usar una PHY. Sin embargo, phylink no se ha desarrollado históricamente con la suspensión/reanudación en mente, y aparentemente no se ha probado demasiado en ese escenario, lo que ha permitido que este error pase desapercibido durante tanto tiempo. Además, antes de WARN_ON(), probablemente habría sido invisible. De hecho, este problema no se limita a los controladores DSA de tipo 2 (según la clasificación ad hoc anterior), sino que se puede extrapolar a cualquier controlador MAC con phylink y operaciones de PM PHY gestionadas por bus MDIO. DSA es justo donde se reportó el problema. Suponiendo que mac_managed_pm esté configurado correctamente, una búsqueda rápida indica que los siguientes controladores podrían estar afectados: $ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c Haga que las condiciones existentes dependan de que el dispositivo PHY tenga una implementación de phydev->phy_link_change() igual al phy_link_change() predeterminado proporcionado por phylib. De lo contrario, sabemos implícitamente que phydev cuenta con la función de devolución de llamada phylink_phy_change() proporcionada por phylink, y cuando se usa phylink, la máquina de estados PHY siempre debe detenerse/iniciar en la ruta de suspensión/reinicio. El código está estructurado de tal manera que, si phydev->phy_link_change() no está presente, es cuestión de tiempo hasta que el kernel se bloquee; no es necesario complicar aún más la prueba. Por lo tanto, si el PM no se gestiona, se trunca.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: Verificar formatos de eventos que contengan "%*p.." El verificador de eventos de rastreo verifica los formatos de los eventos de rastreo para asegurarse de que no apunten a memoria que no esté en el propio evento de rastreo ni a datos que nunca se liberarán. Si un evento hace referencia a datos asignados al momento de su activación y esos mismos datos se liberan antes de la lectura del evento, el kernel puede bloquearse al leer la memoria liberada. El verificador se ejecuta al arrancar (o al cargar un módulo) y analiza los formatos de impresión de los eventos, además de comprobar sus argumentos para garantizar la seguridad de los punteros desreferenciados. Si el formato usa "%*p..", el verificador lo ignorará, lo cual podría ser peligroso. Considere también este caso. Añada también al código de ejemplo un caso de uso de "%*pbl".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Añadir cond_resched() a ftrace_graph_set_hash(). Cuando el kernel contiene una gran cantidad de funciones rastreables, el bucle en ftrace_graph_set_hash() puede tardar mucho en ejecutarse. Esto puede activar el mecanismo de vigilancia de bloqueo suave. Añadir cond_resched() dentro del bucle para que el kernel siga respondiendo incluso al procesar una gran cantidad de funciones. Esto coincide con el cond_resched() utilizado en otras partes del código que itera sobre todas las funciones rastreables.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: códecs: wcd937x: se corrige una posible pérdida de memoria en wcd937x_soc_codec_probe(). Cuando fallan snd_soc_dapm_new_controls() o snd_soc_dapm_add_routes(), wcd937x_soc_codec_probe() regresa sin liberar 'wcd937x->clsh_info', que está asignado por wcd_clsh_ctrl_alloc. Se ha añadido wcd_clsh_ctrl_free() para evitar posibles pérdidas de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libbpf: Se corrige el acceso al encabezado core_relo de BTF.ext. Se actualiza btf_ext_parse_info() para garantizar que el encabezado core_relo esté presente antes de leer sus campos. Esto evita un posible desbordamiento de lectura del búfer reportado por el proyecto OSS Fuzz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel: KVM: Enmascarar PEBS_ENABLE cargado para el invitado con el valor de la vCPU. Al generar el valor MSR_IA32_PEBS_ENABLE que se cargará en VM-Entry a un invitado KVM, enmascarar el valor con el valor PEBS_ENABLE deseado de la vCPU. Consultar únicamente las máscaras de host vs. invitado del kernel del host da como resultado que el invitado se ejecute con PEBS habilitado incluso cuando el invitado no desea usarlo. Debido a que KVM usa eventos perf para proxyizar la PMU virtual del invitado, simplemente mirar exclude_host no puede diferenciar entre eventos creados por el espacio de usuario del host y eventos creados por KVM en nombre del invitado. Ejecutar el invitado con PEBS habilitado inesperadamente generalmente se manifiesta como bloqueos debido a un flujo casi infinito de #PF. Por ejemplo, si el invitado no ha escrito MSR_IA32_DS_AREA, la CPU encontrará fallos de página en la dirección '0' al intentar registrar eventos PEBS. El problema se reproduce más fácilmente ejecutando `perf kvm top` antes de el commit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (tras lo cual, `perf kvm top` dejó de usar PEBS). El lado del espacio de usuario de perf crea un evento PEBS exclusivo para invitados, que intel_guest_get_msrs() malinterpreta como un evento PEBS *propiedad* del invitado. Podría decirse que se trata de un error del espacio de usuario, ya que habilitar PEBS en eventos exclusivos para invitados simplemente no funciona, y el espacio de usuario puede bloquear máquinas virtuales de muchas otras maneras (sin peligro para el host). Sin embargo, incluso si esto se considera un comportamiento inadecuado del espacio de usuario, no hay ninguna desventaja en que perf/KVM restrinja PEBS a eventos propios del invitado. Nota: el commit 854250329c02 ("KVM: x86/pmu: Deshabilitar PEBS invitado temporalmente en dos situaciones excepcionales") corrigió el caso en el que el espacio de usuario del host perfila KVM *y* el espacio de usuario, pero no el caso en el que el espacio de usuario perfila solo KVM.