Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ena: soluciona el comportamiento incorrecto sin descriptor. ENA tiene dos tipos de colas TX: - colas que solo procesan paquetes TX que llegan desde la pila de red - colas que solo procesan paquetes TX reenviados a mediante instrucciones XDP_REDIRECT o XDP_TX. Ena_free_tx_bufs() recorre todos los descriptores en una cola de TX y desasigna + libera todos los descriptores que aún no han sido reconocidos por el dispositivo (transacciones de TX incompletas). La función supone que la cola TX procesada es necesariamente de la primera categoría enumerada anteriormente y termina usando napi_consume_skb() para los descriptores que pertenecen a una cola XDP específica. Este parche resuelve un error por el cual, en caso de restablecer VF, los descriptores no se liberan correctamente, lo que provoca fallos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: vincular correctamente nuevas reglas fs al árbol. Anteriormente, add_rule_fg solo agregaba reglas recién creadas desde el identificador al árbol cuando tenían un recuento de 1. Por otro lado Por otro lado, create_flow_handle se esfuerza por encontrar y hacer referencia a reglas idénticas ya existentes en lugar de crear otras nuevas. Estos dos comportamientos pueden dar lugar a una situación en la que create_flow_handle 1) crea una nueva regla y hace referencia a ella, luego 2) en un paso posterior durante la creación del mismo identificador hace referencia a ella nuevamente, lo que da como resultado una regla con un recuento de 2 que no está vinculada a el árbol, tendrá un padre y una raíz NULL y provocará un bloqueo cuando se elimine el grupo de flujo porque del_sw_hw_rule, invocado al eliminar la regla, asume que nodo->padre es != NULL. Esto sucedió en la naturaleza, debido a otro error relacionado con el manejo incorrecto de identificadores de pkt_reformat duplicados, lo que llevó al código en create_flow_handle a hacer referencia incorrecta a una regla recién agregada en el mismo identificador de flujo, lo que resultó en el problema descrito anteriormente. Los detalles completos están en [1]. Este parche cambia add_rule_fg para agregar nuevas reglas sin padres al árbol, inicializándolas correctamente y evitando el bloqueo. Esto lo hace más coherente con la forma en que se agregan reglas a un FTE en create_flow_handle.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: validación completa de la entrada del usuario En mi confirmación reciente, omití que los controladores do_replace() usan copy_from_sockptr() (que arreglé), seguido de llamadas inseguras copy_from_sockptr_offset(). En todas las funciones, podemos realizar la validación @optlen incluso antes de llamar a xt_alloc_table_info() con la siguiente comprobación: if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL;

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: L2CAP: solución que no valida la entrada del usuario de setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: RFCOMM: solución al no validar la entrada del usuario de setsockopt. Syzbot informó que rfcomm_sock_setsockopt_old() está copiando datos sin verificar la longitud de la entrada del usuario. BUG: KASAN: slab fuera de los límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] BUG: KASAN: slab fuera de los límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] ERROR: KASAN: losa fuera de los límites en rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [en línea] BUG: KASAN: losa fuera de los límites en rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/ sock.c:673 Lectura de tamaño 4 en addr ffff8880209a8bc3 por tarea syz-executor632/5064

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: SCO: la solución no valida la entrada del usuario de setsockopt. syzbot informó que sco_sock_setsockopt() está copiando datos sin verificar la longitud de la entrada del usuario. BUG: KASAN: slab fuera de los límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] BUG: KASAN: slab fuera de los límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] BUG: KASAN: slab fuera de los límites en sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Lectura de tamaño 4 en la dirección ffff88805f7b15a3 mediante la tarea syz-executor.5/12578

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: corrige la condición de ejecución entre ipv6_get_ifaddr e ipv6_del_addr .Aunque ipv6_get_ifaddr recorre inet6_addr_lst bajo el bloqueo de RCU, todavía significa que hlist_for_each_entry_rcu puede devolver un elemento que se eliminó de la lista. La memoria en sí de dicho elemento no se libera gracias a RCU, pero nada garantiza que el contenido real de la memoria sea sano. En particular, el recuento de referencia puede ser cero. Esto puede suceder si se llama a ipv6_del_addr en paralelo. ipv6_del_addr elimina la entrada de inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) y elimina todas las referencias (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). En un momento bastante malo, esto puede suceder: 1. En ipv6_get_ifaddr, hlist_for_each_entry_rcu devuelve una entrada. 2. Luego, se ejecuta todo el ipv6_del_addr para la entrada dada. El recuento de referencias cae a cero y se programa kfree_rcu. 3. ipv6_get_ifaddr continúa e intenta incrementar el recuento de referencias (in6_ifa_hold). 4. Se desbloquea la rcu y se libera la entrada. 5. Se devuelve la entrada liberada. Evite el aumento del recuento de referencia en tal caso. El nombre in6_ifa_hold_safe se elige para imitar el fib6_info_hold_safe existente. [41.506330] refcount_t: suma en 0; uso después de la liberación. [ 41.506760] ADVERTENCIA: CPU: 0 PID: 595 en lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130 [ 41.507413] Módulos vinculados en: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 No contaminado 6.9 .0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130 [ 41.509586] Código: ad ff 90 0f 0b 90 90 c3 cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: 800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP : ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: fffffff8ca58a40 R12: ffff9e9c4339a000 [ 41 .513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) lGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef 0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7 : 0000000000000400 [ 41.516799] Seguimiento de llamadas: [ 41.517037] [ 41.517249] ? __warn+0x7b/0x120 [ 41.517535] ? refcount_warn_saturate+0xa5/0x130 [41.517923]? report_bug+0x164/0x190 [41.518240]? handle_bug+0x3d/0x70 [41.518541]? exc_invalid_op+0x17/0x70 [41.520972]? asm_exc_invalid_op+0x1a/0x20 [41.521325]? refcount_warn_saturate+0xa5/0x130 [ 41.521708] ipv6_get_ifaddr+0xda/0xe0 [ 41.522035] inet6_rtm_getaddr+0x342/0x3f0 [ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10 [ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0 [ 41.523102] ? netlink_unicast+0x30f/0x390 [41.523445]? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 41.523832] netlink_rcv_skb+0x53/0x100 [ 41.524157] netlink_unicast+0x23b/0x390 [ 41.524484] netlink_sendmsg+0x1f2/0x440 [ 41. 524826] __sys_sendto+0x1d8/0x1f0 [ 41.525145] __x64_sys_sendto+0x1f/0x30 [ 41.525467] do_syscall_64+ 0xa5/0x1b0 [41.525794] Entry_SYSCALL_64_after_hwframe+0x72/0x7a [41.526213] RIP: 0033:0x7fbc4cfcea9a [41.526528] Código: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] 002b:00007f-- -truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Asunto: [PATCH] drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Si algunas páginas o la asignación de sgt fallaron, No deberíamos publicar la referencia de páginas que obtuvimos anteriormente, de lo contrario terminaremos con llamadas get/put_pages() desequilibradas. En su lugar, deberíamos dejar todo en su lugar y dejar que la función de liberación de BO se encargue de una limpieza adicional cuando se destruya el objeto, o dejar que el controlador de fallos lo intente nuevamente la próxima vez que se llame.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/ast: corrige el bloqueo suave. Hay un bucle while en ast_dp_set_on_off() que podría generar un bucle infinito. Esto se debe a que el registro, VGACRI-Dx, marcado en esta API es un registro temporal en realidad controlado por una MCU, denominada DPMCU, en BMC. Estos registros de scratch están protegidos por scu-lock. Si suc-lock no está desactivado, DPMCU no puede actualizar estos registros y luego el host tendrá un bloqueo suave debido a que el estado nunca se actualizó. DPMCU se utiliza para controlar DP y los registros relativos al protocolo de enlace con el controlador VGA del host. Incluso la tarea que consume más tiempo, el entrenamiento de enlaces de DP, dura menos de 100 ms. 200 ms deberían ser suficientes.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: accel/ivpu: corrige el punto muerto en context_xa ivpu_device->context_xa está bloqueado tanto en el subproceso del kernel como en el contexto IRQ. Requiere que se pase el indicador XA_FLAGS_LOCK_IRQ durante la inicialización; de lo contrario, el bloqueo podría adquirirse de un subproceso e interrumpirse mediante una IRQ que lo bloquee por segunda vez, provocando el punto muerto. Este punto muerto fue informado por lockdep y observado en pruebas internas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: sg: Evite la ejecución de desmontaje del dispositivo sg sg_remove_sfp_usercontext() no debe usar sg_device_destroy() después de llamar a scsi_device_put(). sg_device_destroy() está accediendo al scsi_device principal request_queue que ya estará configurado en NULL cuando la llamada anterior a scsi_device_put() eliminó la última referencia al scsi_device principal. La excepción de puntero NULL resultante bloqueará el kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: corrige WARN_ON en la ruta de sondeo de iommu. La confirmación 1a75cc710b95 ("iommu/vt-d: usa rbtree para rastrear los dispositivos sondeados por iommu") agrega todos los dispositivos sondeados por iommu. controlador en un rbtree indexado por el ID de origen de cada dispositivo. Se supone que cada dispositivo tiene una identificación de fuente única. Esta suposición es incorrecta y la especificación VT-d tampoco establece este requisito. La razón para usar un rbtree para rastrear dispositivos es buscar el dispositivo con bus PCI y devfunc en las rutas de manejo del error de tiempo de espera de invalidación de ATS y las fallas de la página PRI I/O. Ambos están relacionados con la función PCI ATS. Realice un seguimiento únicamente de los dispositivos que tengan capacidades PCI ATS en el rbtree para evitar WARN_ON innecesario en la ruta de la sonda iommu. De lo contrario, en algunas plataformas inferiores al kernel se mostrará el símbolo y la sonda iommu dará como resultado un error. ADVERTENCIA: CPU: 3 PID: 166 en drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90 Seguimiento de llamadas: ? __warn+0x7e/0x180 ? intel_iommu_probe_device+0x319/0xd90? report_bug+0x1f8/0x200? handle_bug+0x3c/0x70? exc_invalid_op+0x18/0x70? asm_exc_invalid_op+0x1a/0x20? intel_iommu_probe_device+0x319/0xd90? debug_mutex_init+0x37/0x50 __iommu_probe_device+0xf2/0x4f0 iommu_probe_device+0x22/0x70 iommu_bus_notifier+0x1e/0x40 notifier_call_chain+0x46/0x150 blocking_notifier_call_chain+0x42/0x60 bus_notify+0 x2f/0x50 device_add+0x5ed/0x7e0 platform_device_add+0xf5/0x240 mfd_add_devices+0x3f9/0x500 ? preempt_count_add+0x4c/0xa0? up_write+0xa2/0x1b0? __debugfs_create_file+0xe3/0x150 intel_lpss_probe+0x49f/0x5b0? pci_conf1_write+0xa3/0xf0 intel_lpss_pci_probe+0xcf/0x110 [intel_lpss_pci] pci_device_probe+0x95/0x120 really_probe+0xd9/0x370? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x73/0x150 driver_probe_device+0x19/0xa0 __driver_attach+0xb6/0x180 ? __pfx___driver_attach+0x10/0x10 bus_for_each_dev+0x77/0xd0 bus_add_driver+0x114/0x210 driver_register+0x5b/0x110 ? __pfx_intel_lpss_pci_driver_init+0x10/0x10 [intel_lpss_pci] do_one_initcall+0x57/0x2b0? kmalloc_trace+0x21e/0x280? do_init_module+0x1e/0x210 do_init_module+0x5f/0x210 load_module+0x1d37/0x1fc0 ? init_module_from_file+0x86/0xd0 init_module_from_file+0x86/0xd0 idempotent_init_module+0x17c/0x230 __x64_sys_finit_module+0x56/0xb0 do_syscall_64+0x6e/0x140 Entry_SYSCALL_64_after_hwframe+0x71 /0x79