Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: icmp: evita posibles desreferencias a NULL por parte de icmp_build_probe(). El primer problema es una doble llamada a __in_dev_get_rcu(), porque la segunda podría devolver NULL. if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list) El segundo problema es una lectura de dev->ip6_ptr sin verificación NULL: if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list)) Use el correcto API de RCU para solucionarlos. v2: agregar falta incluir

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bcmasp: corrige la pérdida de memoria al desactivar la interfaz. Al desactivar los anillos TX, los limpiamos pero nos olvidamos de recuperar los paquetes eliminados. Esto provoca una pérdida de memoria ya que no liberamos los búfers asignados por dma. Esto también conduce a la corrupción del bloque de control de transmisión al desactivar la interfaz para la administración de energía.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloquear: reparar la fuga de referencia del módulo de la ruta de error bdev_open_by_dev. En el momento en que se llama a bdev_may_open(), la referencia del módulo ya está tomada, por lo tanto, la referencia del módulo debe liberarse si bdev_may_open() fallo. Este problema se encuentra mediante la revisión del código.

Una vulnerabilidad ha sido encontrada en SourceCodester Gas Agency Management System 1.0 y clasificada como crítica. Esta vulnerabilidad afecta a un código desconocido del archivo edituser.php. La manipulación del argumento id conduce a la inyección de SQL. El ataque se puede iniciar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador de esta vulnerabilidad es VDB-264748.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: Corrige pérdida de memoria al cancelar trabajo de rehash El trabajo retrasado de rehash se reprograma con retraso si el número de créditos al final del trabajo no es negativo como supuestamente significa que la migración terminó. En caso contrario, se reprograma inmediatamente. Después de "mlxsw: espectro_acl_tcam: Corregir posible use after free durante la repetición", lo anterior ya no es exacto ya que una cantidad no negativa de créditos ya no es indicativo de la migración que se está realizando. También puede suceder si el trabajo encontró un error, en cuyo caso la migración se reanudará la próxima vez que se programe el trabajo. La importancia de lo anterior es que es posible que el trabajo esté pendiente y asociado con sugerencias que se asignaron cuando comenzó la migración. Esto lleva a que se filtren sugerencias [1] cuando el trabajo se cancela mientras está pendiente como parte del desmantelamiento de la región ACL. Se soluciona liberando las sugerencias si las sugerencias están asociadas con un trabajo que se canceló mientras estaba pendiente. Culpe al compromiso original, ya que la dependencia de no tener un trabajo pendiente asociado con sugerencias es frágil. [1] objeto sin referencia 0xffff88810e7c3000 (tamaño 256): comm "kworker/0:16", pid 176, jiffies 4295460353 volcado hexadecimal (primeros 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 80 . 0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... retroceso (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] 0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] proceso_one_work+ 0x59c/0xf20 [<00000000ceee9e81>] work_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<0000 0000dea2b93e>] 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: 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.