Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: mlxsw: spectrum_acl_tcam: Corrige posible use after free durante el rehash El trabajo retrasado del rehash migra filtros de una región a otra según la cantidad de créditos disponibles. La región que ha migrado se destruye al final del trabajo si el número de créditos no es negativo, ya que se supone que esto es indicativo de que la migración se ha completado. Esta suposición es incorrecta ya que una cantidad no negativa de créditos también puede ser el resultado de una migración fallida. La destrucción de una región que todavía tiene filtros que hacen referencia a ella puede resultar en un use after free [1]. Solución al no destruir la región si la migración fallo. [1] ERROR: KASAN: slab-use-after-free en mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 Lectura del tamaño 8 en la dirección ffff8881735319e8 por tarea kworker/0:31/3858 CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted : GW 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Nombre de hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work Seguimiento de llamadas: dump_stack_lvl+ 0xc6/0x120 imprimir_informe+ 0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 _tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 Process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+ 0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Asignado por tarea 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 _tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb /0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14 /0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: spectrum_acl_tcam: corrige posible use after free durante la actualización de la actividad. El trabajo retrasado de la actualización de la actividad de la regla recorre periódicamente la lista de reglas configuradas y consulta su actividad desde el dispositivo. Como parte de esta tarea, accede a la entrada señalada por 'ventry->entry', pero esta entrada puede cambiarse simultáneamente mediante el trabajo retrasado del rehash, lo que lleva a un use after free [1]. Para solucionarlo, cierre la ejecución y realice la consulta de actividad en el mutex 'vregion->lock'. [1] ERROR: KASAN: slab-use-after-free en mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Lectura del tamaño 8 en la dirección ffff8881054ed808 por tarea kworker/0:18/181 CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_rule_activity_update_work Seguimiento de llamadas: dump_stack_lvl+0xc 6/0x120 print_report+0xce /0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 Process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Asignado por tarea 1039 : kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x 30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/ 0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Liberado por la tarea 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/ 0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x 30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btusb: mediatek: Corrección double free de skb en coredump hci_devcd_append() liberaría el skb en caso de error para que la persona que llama no tenga que liberarlo nuevamente, de lo contrario causaría el doble libre de skb. Reportado por: Dan Carpenter

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: bridge: reemplace physindev con physinif en nf_bridge_info. Se puede agregar un skb a neigh->arp_queue mientras se espera una respuesta de arp. Donde skb->dev del skb original puede ser diferente al neigh->dev de neigh. Por ejemplo, en el caso de unir un skb designado de un veth a otro, el skb se agregaría a un vecino->arp_queue del puente. Como skb->dev se puede restablecer a nf_bridge->physindev y usarse, y como no existe un mecanismo explícito que impida que este physindev se libere bajo nuestra responsabilidad (por ejemplo, neigh_flush_dev no limpia skbs de la cola vecina de diferentes dispositivos), podemos crashear, por ejemplo, en esta pila: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Usemos ifindex simple en lugar de enlace net_device. Para echar un vistazo al net_device original usaremos dev_get_by_index_rcu(). Por lo tanto, o obtenemos el dispositivo y podemos usarlo con seguridad o no lo obtenemos y eliminamos skb.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: use OPTION_MPTCP_MPJ_SYNACK en subflow_finish_connect() subflow_finish_connect() usa cuatro campos (backup, join_id, thmac, none) que pueden contener basura a menos que se haya configurado OPTION_MPTCP_MPJ_SYNACK en mptcp_parse_option()

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: tls, corrija la ADVERTENCIA en __sk_msg_free Un empalme con MSG_SPLICE_PAGES hará que el código tls use la ruta tls_sw_sendmsg_splice en el código TLS sendmsg para mover las páginas proporcionadas por el usuario del msg al msg_pl . Esto recorrerá el mensaje hasta que msg_pl esté lleno, verificado por sk_msg_full(msg_pl). El usuario también puede configurar el indicador MORE para que la pila de sugerencias retrase el envío hasta recibir más páginas e idealmente un búfer completo. Si el usuario agrega más páginas al mensaje de las que caben en la lista de dispersión msg_pl (MAX_MSG_FRAGS), debemos ignorar el indicador MÁS y enviar el búfer de todos modos. Sin embargo, lo que realmente sucede es que abortamos la configuración de la lista de dispersión de msg a msg_pl y luego, como nos olvidamos de configurar el 'registro completo', lo que indica que ya no podemos consumir datos sin un envío, pasamos a la ruta 'continuar' que verificará si msg_data_left(msg) tiene más bytes para enviar y luego intenta incluirlos en el msg_pl que ya está completo. Luego, la próxima iteración del remitente que realiza el envío encontrará un msg_pl completo y arrojará la advertencia en el informe syzbot. Para solucionarlo, simplemente verifique si tenemos un registro completo en la ruta del código de empalme y, si no, envíe el mensaje independientemente del indicador MORE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: sof-common: Agregar verificación NULL para la cadena normal_link No se garantiza que todas las entradas de la estructura sof_conn_stream declaren una cadena `normal_link` (un enlace directo no SOF) , y este es el caso de los SoC que solo admiten rutas SOF (por lo tanto, no admiten casos de uso directos y SOF). Por ejemplo, en el caso de MT8188 no hay una cadena normal_link en ninguna de las entradas de sof_conn_stream y habrá más controladores que lo hagan en el futuro. Para evitar posibles KP de puntero NULL, agregue una verificación NULL para `normal_link`.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/vt-d: use el rbtree del dispositivo en la ruta de informes iopf. El controlador de fallos de la página de E/S existente actualmente ubica el dispositivo PCI llamando a pci_get_domain_bus_and_slot(). Esta función busca en la lista de todos los dispositivos PCI hasta encontrar el dispositivo deseado. Para mejorar la eficiencia de la búsqueda, reemplácelo con device_rbtree_find() para buscar el dispositivo dentro del rbtree del dispositivo probado. El fallo de la página de E/S la inicia el dispositivo, que no tiene ningún mecanismo de sincronización con el software para garantizar que el dispositivo permanezca en el árbol de dispositivos analizados. En teoría, el subsistema IOMMU podría liberar un dispositivo después de device_rbtree_find() y antes de iopf_get_dev_fault_param(), lo que causaría un problema de uso después de la liberación. Agregue un mutex para sincronizar la ruta de informe de fallos de la página de E/S y la ruta del dispositivo de liberación IOMMU. Este bloqueo no introduce ninguna sobrecarga de rendimiento, ya que el conflicto entre el informe de fallos de la página de E/S y la liberación del dispositivo es muy raro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: compress: corrige el error de conteo de reserve_cblocks cuando no hay espacio. Cuando un archivo solo necesita un direct_node, realizar las siguientes operaciones hará que el archivo no se pueda reparar: unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4,8M 100% /data unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3,0 M) copiados, 0,025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS falló: no queda espacio en el dispositivo adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0 Esto se debe a que el archivo tiene solo un nodo_directo. Después de regresar a -ENOSPC, reserve_blocks += ret no se ejecutará. Como resultado, los bloques_reservados en este momento siguen siendo 0, que no es el número real de bloques reservados. Por lo tanto, no se puede configurar fsck para reparar el archivo. Después de este parche, se configurará el indicador fsck para solucionar este problema. unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS falló: no queda espacio en el dispositivo y al reinicio del adb luego se ejecutará fsck unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 924

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: dbg-tlv: asegurar terminación NUL. El iwl_fw_ini_debug_info_tlv se usa como una cadena, por lo que debemos asegurarnos de que la cadena termine correctamente antes de usarla.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: zswap: corrige el bloqueo NULL del reductor con cgroup_disable=memory. Christian informa una deref NULL en zswap que dividió en dos hasta el reductor zswap. El problema también surgió en los rastreadores de errores de libguestfs [1] y Red Hat bugzilla [2]. El problema es que cuando memcg está deshabilitado con el indicador de tiempo de arranque, es posible que se llame al reductor zswap con sc->memcg == NULL. Esto está bien en muchos lugares, como en las operaciones de lruvec. Pero fallo en memcg_page_state(), que para empezar solo se usa debido a la contabilidad sin nodos de la memoria zswap de cgroup. Nhat detectó que memcg puede ser NULL en el caso de que memcg esté deshabilitado y luego también pude reproducir el fallo localmente. [1] https://github.com/libguestfs/libguestfs/issues/139 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2275252

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: irqchip/gic-v3-its: Evitar el double free en caso de error. La ruta de manejo de errores en its_vpe_irq_domain_alloc() provoca un double free cuando its_vpe_init() falla después de asignar exitosamente al menos una interrupción. Esto sucede porque its_vpe_irq_domain_free() libera las interrupciones junto con el mapa de bits del área y la vprop_page y its_vpe_irq_domain_alloc() posteriormente libera nuevamente el mapa de bits del área y la vprop_page. Solucione este problema invocando incondicionalmente its_vpe_irq_domain_free() que maneja todos los casos correctamente y eliminando el mapa de bits/vprop_page que se libera de its_vpe_irq_domain_alloc().