Vulnerabilidades

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).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Aumentar el tamaño de la matriz de dummy_boolean [POR QUÉ] dml2_core_shared_mode_support y dml_core_mode_support acceden al tercer elemento de dummy_boolean, es decir, hw_debug5 = &s->dummy_boolean[2], cuando dummy_boolean tiene un tamaño de 2. Cualquier asignación a hw_debug5 provoca un OVERRUN. [CÓMO] Aumentar el tamaño de la matriz de dummy_boolean a 3. Esto corrige 2 problemas de OVERRUN informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Desasignar memoria DML si falla la asignación [Por qué] Cuando falla la asignación de memoria DML al crear un estado de DC, la memoria no se desasigna posteriormente, lo que da como resultado una estructura no inicializada que no es NULL. [Cómo] Desasignar memoria si falla la asignación de memoria DML.