Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/hdcp: Verificar la validez de la estructura GSC En ocasiones, xe_gsc no se inicializa cuando se verifica en la verificación de capacidad HDCP. Agregar verificación de estructura gsc para evitar errores de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige el bloqueo potencial si se llama a qi_submit_sync con un recuento de 0 Si se invoca qi_submit_sync() con 0 descriptores de invalidación (por ejemplo, para fines de vaciado de DMA), podemos encontrarnos con un error en el que un hilo de envío no detecta la finalización de invalidation_wait. Posteriormente, esto condujo a un bloqueo suave. Actualmente, este error no tiene impacto en los usuarios existentes porque ningún llamante está enviando invalidaciones con 0 descriptores. Esta corrección permitirá a los futuros usuarios (como DMA drain) llamar a qi_submit_sync() con un recuento de 0. Supongamos que el hilo T1 invoca qi_submit_sync() con descriptores distintos de cero, mientras que, al mismo tiempo, el hilo T2 llama a qi_submit_sync() con cero descriptores. Ambos hilos entran entonces en un bucle while, esperando a que se completen sus respectivos descriptores. T1 detecta su finalización (es decir, el estado invalidation_wait de T1 cambia a QI_DONE por HW) y procede a llamar a reclaim_free_desc() para recuperar todos los descriptores, incluyendo potencialmente los adyacentes de otros subprocesos que también están marcados como QI_DONE. Durante este tiempo, mientras T2 espera adquirir el qi->q_lock, el hardware IOMMU puede completar la invalidación para T2, estableciendo su estado en QI_DONE. Sin embargo, si la ejecución de reclaim_free_desc() por parte de T1 libera el descriptor invalidation_wait de T2 y cambia su estado a QI_FREE, T2 no observará el estado QI_DONE para su invalidation_wait y permanecerá bloqueado indefinidamente. Este bloqueo suave no ocurre cuando solo se envían descriptores distintos de cero. En tales casos, los descriptores de invalidación se intercalan entre los descriptores de espera con el estado QI_IN_USE, actuando como barreras. Estas barreras evitan que el código de recuperación libere por error descriptores que pertenecen a otros remitentes. Considere la siguiente línea de tiempo de ejemplo: T1 T2 ========================================= ID1 WD1 while(WD1!=QI_DONE) unlock lock WD1=QI_DONE* WD2 while(WD2!=QI_DONE) unlock lock WD1==QI_DONE? ID1=QI_DONE WD2=DONE* reclaim() ID1=FREE WD1=FREE WD2=FREE unlock soft lockup! T2 nunca ve QI_DONE en WD2 Donde: ID = descriptor de invalidación WD = descriptor de espera * Escrito por hardware La raíz del problema es que el indicador de estado del descriptor QI_DONE se usa para dos propósitos conflictivos: 1. señalar que un descriptor está listo para ser recuperado (para ser liberado) 2. señalar por el hardware que un descriptor de espera está completo La solución (en este parche) es la separación de estados mediante el uso del indicador QI_FREE para #1. Una vez que los descriptores de invalidación de un hilo están completos, su estado se establecería en QI_FREE. La función reclaim_free_desc() solo liberaría los descriptores marcados como QI_FREE en lugar de los marcados como QI_DONE. Este cambio asegura que T2 (del ejemplo anterior) observará correctamente la finalización de su invalidation_wait (marcada como QI_DONE).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: protección contra el desbordamiento de búfer de cadena Smatch informa que copiar media_name e if_name a name_parts puede sobrescribir el destino. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' demasiado grande para 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' demasiado grande para 'name_parts->if_name' (1010102 vs 16) Este parece ser el caso, así que protéjase contra esta posibilidad usando strscpy() y fallando si ocurre un truncamiento. Introducido por el commit b97bf3fd8f6a ("[TIPC] Fusión inicial") Compilación probada únicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Arreglar la configuración del indicador de respuesta del servidor En afs_wait_for_operation(), configuramos la transcripción del indicador de respuesta de llamada en el registro del servidor que usamos después de realizar el bucle de iteración del servidor de archivos, pero es posible salir del bucle después de haber recibido una respuesta del servidor que descartamos (por ejemplo, devolvió un aborto o comenzamos a recibir datos, pero la llamada no se completó). Esto significa que op->server podría ser NULL, pero no lo verificamos antes de intentar configurar el indicador del servidor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir desbordamiento de entero en BLKSECDISCARD Descubrí de forma independiente el commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 bloque: corregir desbordamiento en blk_ioctl_discard() pero para borrado seguro. Mismo problema: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); entrará en un bucle casi infinito dentro de blkdev_issue_secure_erase(): a.out: intento de acceso más allá del final del dispositivo loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 devoluciones de llamadas suprimidas

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige el desbordamiento de búfer al analizar los puntos de análisis de NFS ReparseDataLength es la suma del tamaño de InodeType y el tamaño de DataBuffer. Por lo tanto, para obtener el tamaño de DataBuffer, es necesario restar el tamaño de InodeType de ReparseDataLength. La función cifs_strndup_from_utf16() está accediendo actualmente a buf->DataBuffer en la posición después del final del búfer porque no resta el tamaño de InodeType de la longitud. Solucione este problema y reste correctamente la variable len. El miembro InodeType solo está presente cuando el búfer de análisis es lo suficientemente grande. Verifique ReparseDataLength antes de acceder a InodeType para evitar otro acceso no válido a la memoria. Los valores rdev principales y secundarios también están presentes solo cuando el búfer de análisis es lo suficientemente grande. Verifique el tamaño del búfer de análisis antes de llamar a reparse_mkdev().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: se soluciona el problema de doble liberación durante la descarga del módulo amdgpu Los endpoints flexibles usan DIG de endpoints inflexibles disponibles, por lo que solo es necesario liberar los codificadores de enlaces inflexibles. De lo contrario, puede ocurrir un problema de doble liberación al descargar el módulo amdgpu. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Seguimiento de llamadas: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [279.190601]? do_error_trap+0x73/0xa0 [279.190605]? __slab_free+0x152/0x2f0 [279.190609]? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [279.191102]? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] /0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] ister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939 ] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: x86-android-tablets: Se corrige el use after free en errores platform_device_register() x86_android_tablet_remove() libera la matriz pdevs[], por lo que no se debe utilizar después de llamar a x86_android_tablet_remove(). cuando falla platform_device_register(), almacena el valor PTR_ERR() de pdevs[x] en la variable ret local antes de llamar a x86_android_tablet_remove() para evitar usar pdevs[] después de que se haya liberado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: amdkfd_free_gtt_mem borra el puntero correcto. Pase la referencia del puntero a amdgpu_bo_unref para borrar el puntero correcto; de lo contrario, amdgpu_bo_unref borra la variable local, el puntero original no está establecido en NULL, esto podría causar un error de use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/stm: Evite problemas de use after free con crtc y plane ltdc_load() llama a las funciones drm_crtc_init_with_planes(), drm_universal_plane_init() y drm_encoder_init(). Estas funciones no deben llamarse con parámetros asignados con devm_kzalloc() para evitar problemas de use after free [1]. Use asignaciones administradas por el framework DRM. Encontrado por Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: lantiq_etop: fix memory breach Al aplicar relleno, el búfer no se pone a cero, lo que da como resultado la divulgación de memoria. Los datos mencionados se observan en el cable. Este parche usa skb_put_padto() para rellenar los marcos Ethernet correctamente. La función mencionada pone a cero el búfer expandido. En caso de que el paquete no se pueda rellenar, se descarta silenciosamente. Las estadísticas tampoco se incrementan. Este controlador no admite estadísticas en el antiguo formato de 32 bits ni en el nuevo formato de 64 bits. Estos se agregarán en el futuro. En su forma actual, el parche debería poder retroportarse fácilmente a versiones estables. Las MAC de Ethernet en Amazon-SE y Danube no pueden realizar relleno de los paquetes en hardware, por lo que se debe aplicar relleno de software.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mejorar la secuencia de apagado Alexander Sverdlin presenta 2 problemas durante el apagado con el controlador lan9303. Uno es específico de lan9303 y el otro simplemente se reproduce allí. El primer problema es que lan9303 es único entre los controladores DSA en el sentido de que llama a dev_get_drvdata() en un "tiempo de ejecución arbitrario" (no sondeo, no apagado, no eliminación): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() Pero nunca detenemos phy_state_machine(), por lo que puede continuar ejecutándose después de dsa_switch_shutdown(). Nuestro patrón común en todos los controladores DSA es establecer drvdata en NULL para suprimir el método remove() que puede venir después. Pero en este caso resultará en un NPD. El segundo problema es que la forma en que establecemos dp->conduit->dsa_ptr = NULL; es concurrente con el procesamiento de paquetes de recepción. dsa_switch_rcv() verifica una vez si dev->dsa_ptr es NULL, pero después, en lugar de continuar usando ese valor no NULL, dev->dsa_ptr se desreferencia una y otra vez sin verificaciones NULL: dsa_conduit_find_user() y muchos otros lugares. Entre desreferencias, no hay bloqueo para asegurar que lo que era válido una vez continúa siendo válido. Ambos problemas tienen el aspecto común de que cerrar la interfaz del conducto los resuelve. En el primer caso, dev_close(conduit) activa el evento NETDEV_GOING_DOWN en dsa_user_netdevice_event() que también cierra los puertos de usuario. dsa_port_disable_rt() llama a phylink_stop(), que detiene sincrónicamente la máquina de estado de phylink, y ds->ops->phy_read() ya no llamará al controlador después de este punto. En el segundo caso, dev_close(conduit) debería hacer esto, según Documentation/networking/driver.rst: | Quiescence | ---------- | | Después de que se haya llamado a la rutina ndo_stop, el hardware no debe recibir ni transmitir ningún dato. Todos los paquetes en tránsito deben ser abortados. Si es necesario, sondee o espere a que se completen los comandos de reinicio. Por lo tanto, debería ser suficiente para garantizar que más adelante, cuando pongamos a cero conduit->dsa_ptr, no habrá ninguna llamada dsa_switch_rcv() concurrente en este conducto. La adición de la función netif_device_detach() es para garantizar que las solicitudes ioctls, rtnetlinks y ethtool en los puertos de usuario ya no se propaguen al controlador; ya no estamos preparados para manejarlas. La condición de ejecución en realidad no existía cuando el commit 0650bf52b31f ("net: dsa: sea compatible con los maestros que cancelan el registro al apagar") introdujo por primera vez dsa_switch_shutdown(). Se creó más tarde, cuando dejamos de cancelar el registro de las interfaces de usuario desde un lugar incorrecto y simplemente reemplazamos esa secuencia con una puesta a cero de ejecución de conduit->dsa_ptr (que no garantiza que las interfaces no estén activas).