Vulnerabilidades

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: 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 resolvió la siguiente vulnerabilidad: mlxsw: spectrum_acl_tcam: corrige la pérdida de memoria durante el rehash El trabajo retrasado del rehash migra los filtros de una región a otra. Esto se hace iterando sobre todos los fragmentos (todos los filtros con la misma prioridad) en la región y en cada fragmento iterando sobre todos los filtros. Si la migración fallo, el código intenta migrar los filtros nuevamente a la región anterior. Sin embargo, la reversión en sí también puede fallor, en cuyo caso se realizará otra migración por error. Además de que este ping pong no es una muy buena idea, también crea un problema. Cada fragmento virtual hace referencia a dos fragmentos: el que se utiliza actualmente ('vchunk->chunk') y una copia de seguridad ('vchunk->chunk2'). Durante la migración, el primero contiene el fragmento al que queremos migrar los filtros y el segundo contiene el fragmento desde el que estamos migrando los filtros. Actualmente, el código supone, pero no verifica, que el fragmento de copia de seguridad no existe (NULL) si el fragmento utilizado actualmente no hace referencia a la región de destino. Esta suposición se rompe cuando intentamos revertir una reversión, lo que provoca que el fragmento de copia de seguridad se sobrescriba y se filtre [1]. Corrija al no revertir una reversión fallida y agregue una advertencia para evitar casos futuros. [1] ADVERTENCIA: CPU: 5 PID: 1063 en lib/parman.c:291 parman_destroy+0x17/0x20 Módulos vinculados en: CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: GW 6.9.0-rc2- custom-00784-gc6a05c468a0b #14 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:parman_destroy+0x17/0x20 [...] : mlxsw_sp_acl_atcam_region_fini +0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 proceso_one_work+0x151/0x370 trabajador_hilo+0x2cb/0x3e0 kthread+0xd0/0x100 k+0x34/0x50 ret_from_fork_asm+0x1a/0x30

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 resolvió la siguiente vulnerabilidad: eeprom: at24: corrige la condición de ejecución por corrupción de memoria. Si no se puede acceder a la eeprom, se registrará un dispositivo nvmem, la lectura fallará y el dispositivo se apagará. Si otro controlador accede al dispositivo nvmem después del desmontaje, hará referencia a una memoria no válida. Mueva el punto de fallo antes de registrar el dispositivo nvmem.

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 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: btrfs: corrige la fuga de información en btrfs_ioctl_logic_to_ino() Syzbot informó la siguiente fuga de información en btrfs_ioctl_logic_to_ino(): ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h: 114 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [en línea] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [en línea] btrfs_ioctl_logic_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c :904 [en línea] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h: 17 do_syscall_x64 arco/ x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se creó en: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [en línea] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [en línea] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc incluye /linux/slab.h:766 [en línea] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logic_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 ctl fs/ioctl.c :51 [en línea] __do_sys_ioctl fs/ioctl.c:904 [en línea] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x Arco 3b50/x86/incluye /generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 de 65536 no están inicializados El acceso a la memoria de tamaño 65536 comienza en ffff888045a40000. Esto sucede porque estamos copiando una 'estructura btrfs_data_container' nuevamente al espacio de usuario. Este btrfs_data_container se asigna en 'init_data_container()' a través de kvmalloc(), que no llena la memoria con ceros. Solucione este problema usando kvzalloc() que pone a cero la memoria al asignarla.

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