Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: soluciona el fallo debido a copy_map_value incorrecto Cuando tanto bpf_spin_lock como bpf_timer están presentes en un valor de mapa BPF, copy_map_value necesita eludir ambos objetos al copiar un valor dentro y fuera del mapa. Sin embargo, el código actual no establece s_off y t_off en copy_map_value, lo que provoca un bloqueo cuando, por ejemplo, bpf_spin_lock se coloca en el valor del mapa con bpf_timer, ya que la llamada a bpf_map_update_elem podrá sobrescribir el otro objeto de temporizador. Cuando el problema no se soluciona, una sobrescritura puede producir el siguiente símbolo: [root@(none) bpf]# ./test_progs -t timer_crash [15.930339] bpf_testmod: cargando el núcleo de contaminación del módulo fuera del árbol. [16.037849] ================================================= =================== [16.038458] ERROR: KASAN: acceso a memoria de usuario en __pv_queued_spin_lock_slowpath+0x32b/0x520 [16.038944] Escritura de tamaño 8 en la dirección 0000000000043ec0 por tarea test_progs /325 [ 16.039399] [ 16.039514] CPU: 0 PID: 325 Comm: test_progs Contaminado: G OE 5.16.0+ #278 [ 16.039983] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0- 1 01/04/2014 [ 16.040485] Seguimiento de llamadas: [ 16.040645] [ 16.040805] dump_stack_lvl+0x59/0x73 [ 16.041069] ? __pv_queued_spin_lock_slowpath+0x32b/0x520 [ 16.041427] kasan_report.cold+0x116/0x11b [ 16.041673] ? __pv_queued_spin_lock_slowpath+0x32b/0x520 [16.042040] __pv_queued_spin_lock_slowpath+0x32b/0x520 [16.042328] ? memcpy+0x39/0x60 [16.042552]? pv_hash+0xd0/0xd0 [16.042785]? lockdep_hardirqs_off+0x95/0xd0 [ 16.043079] __bpf_spin_lock_irqsave+0xdf/0xf0 [ 16.043366] ? bpf_get_current_comm+0x50/0x50 [16.043608]? jhash+0x11a/0x270 [ 16.043848] bpf_timer_cancel+0x34/0xe0 [ 16.044119] bpf_prog_c4ea1c0f7449940d_sys_enter+0x7c/0x81 [ 16.044500] 7838_0+0x36/0x1000 [ 16.044836] __x64_sys_nanosleep+0x5/0x140 [ 16.045119] do_syscall_64+0x59/0x80 [ 16.045377] ? lock_is_held_type+0xe4/0x140 [16.045670]? irqentry_exit_to_user_mode+0xa/0x40 [16.046001]? mark_held_locks+0x24/0x90 [16.046287]? asm_exc_page_fault+0x1e/0x30 [16.046569]? asm_exc_page_fault+0x8/0x30 [16.046851]? lockdep_hardirqs_on+0x7e/0x100 [16.047137] Entry_SYSCALL_64_after_hwframe+0x44/0xae [16.047405] RIP: 0033:0x7f9e4831718d [16.047602] Código: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48 [ 16.048764] : 002b:00007fff488086b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000023 [ 16.049275] RAX: ffffffffffffffda RBX: 00007f9e48683740 RCX: 00007f9e4831718d [ 16.049747] RDX: 000000000000 RSI: 0000000000000000 RDI: 00007fff488086d0 [ 16.050225] RBP: 00007fff488086f0 R08: 00007fff488085d7 R09: 00007f9e4cb594a0 [ 16.050648] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f9e484cde30 [ 16.051124] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 16.051608 ] [ 16.051762] ========================= ============================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige el restablecimiento y la eliminación simultáneos de VF. El commit c503e63200c6 ("ice: deja de procesar mensajes VF durante el desmontaje") introdujo un indicador de estado del controlador, ICE_VF_DEINIT_IN_PROGRESS, cuyo objetivo es evitar algunos problemas con el manejo simultáneo de mensajes de VF mientras se derriban los VF. Este cambio fue motivado por accidentes causados al derribar y levantar VF en rápida sucesión. Resulta que la solución en realidad introduce problemas con el controlador VF causados porque el PF ya no responde a ningún mensaje enviado por el VF durante su rutina .remove. Esto da como resultado que el VF elimine potencialmente su memoria DMA antes de que el PF haya cerrado las colas de dispositivos. Además, la solución en realidad no resuelve los problemas de concurrencia dentro del controlador Ice. Es posible que un VF inicie un reinicio justo antes de que el driver de hielo elimine los VF. Esto puede provocar que la tarea de eliminación funcione simultáneamente mientras se restablece el VF. Esto da como resultado una corrupción de memoria similar y pánicos supuestamente solucionados por esa confirmación. Corrija esta simultaneidad desde la raíz protegiendo los flujos de reinicio y eliminación utilizando el VF cfg_lock existente. Esto garantiza que no podamos eliminar el VF mientras se estén realizando tareas críticas pendientes, como un mensaje virtchnl o un reinicio. Este cambio de bloqueo también soluciona la causa raíz solucionada originalmente mediante el commit c503e63200c6 ("ice: Detener el procesamiento de mensajes VF durante el desmontaje"), por lo que simplemente podemos revertirlo. Tenga en cuenta que mantuve estos dos cambios juntos porque simplemente revertir el compromiso original dejaría al driver vulnerable a peores condiciones de ejecución.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: configfs: arregla una ejecución en configfs_{,un}register_subsystem() Cuando configfs_register_subsystem() o configfs_unregister_subsystem() está ejecutando link_group() o unlink_group(), es posible que dos procesos agregar o eliminar la lista al mismo tiempo. Algunas intercalaciones desafortunadas de ellos pueden causar pánico en el kernel. Uno de los casos es: A --> B --> C --> DA <-- B <-- C <-- D eliminar list_head *B | eliminar list_head *C --------------------------------|------------- ---------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | desvincular_grupo desvincular_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // siguiente == C | siguiente->anterior = anterior | | siguiente->anterior = anterior anterior->siguiente = siguiente | | // anterior == B | prev->next = next Solucione esto agregando mutex al llamar a link_group() o unlink_group(), pero el configfs_subsystem principal es NULL cuando config_item es root. Entonces creo un mutex configfs_subsystem_mutex.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: DR, corrigió slab-out-of-bounds en mlx5_cmd_dr_create_fte Al agregar una regla con 32 destinos, encontramos el siguiente problema de acceso fuera de banda: ERROR: KASAN: slab-out-of-bounds en mlx5_cmd_dr_create_fte+0x18ee/0x1e70 Este parche soluciona el problema aumentando los búferes asignados para acomodar las acciones necesarias y verificando la cantidad de acciones para evitar este problema cuando una regla con demasiadas acciones se proporciona.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige la pérdida de memoria durante la actualización de objetos con estado. Los objetos con estado se pueden actualizar desde el plano de control. La lógica de transacción asigna un objeto temporal para este propósito. La función ->init fue llamada para este objeto, por lo que kfree() simple pierde recursos. Debemos llamar a la función ->destruir del objeto. nft_obj_destroy hace esto, pero también disminuye el recuento del módulo, pero la ruta de actualización no lo incrementa. Para evitar usar mayúsculas y minúsculas especiales en la versión del objeto de actualización, utilice module_get para el caso de actualización también y libérela mediante nft_obj_destroy().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfp: flower: corrige una fuga potencial en nfp_tunnel_add_shared_mac() ida_simple_get() devuelve una identificación entre min (0) y max (NFP_MAX_MAC_INDEX) incluida. Entonces NFP_MAX_MAC_INDEX (0xff) es una identificación válida. Para que la ruta de manejo de errores funcione correctamente, el valor 'no válido' para 'ida_idx' no debe estar en el rango 0..NFP_MAX_MAC_INDEX, incluida. Así que configúrelo en -1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: anular el registro de los ganchos de la tabla de flujo en la salida de netns. Anular el registro de los ganchos de la tabla de flujo antes de que se publiquen a través de nf_tables_flowtable_destroy(); de lo contrario, enganche los informes centrales UAF. ERROR: KASAN: use-after-free en nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 Lectura de tamaño 4 en la dirección ffff8880736f7438 por la tarea syz-executor579/3666 CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c :88 [en línea] __dump_stack lib/dump_stack.c:88 [en línea] lib/dump_stack.c:106 dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106 print_address_description+0x65/0x380 mm/kasan /report.c:247 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [en línea] __kasan_report mm/kasan/report.c:433 [en línea] mm/kasan/report.c:450 kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450 nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 __nf_register_net_hook+0x27e/ 0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429 nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571 nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter /nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232 nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430 nfnetlink_rcv_batch net/netfilter/nfnetlink .c:513 [en línea ] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [en línea] nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [en línea] net/netfilter/nfnetlink.c:652 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [en línea] neto /netfilter/nfnetlink.c:652 nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652 __nft_release_hook() llama a nft_unregister_flowtable_net_hooks() que solo cancela el registro de los ganchos, luego, después del período de gracia de RCU, se garantiza que ningún paquete agregue nuevas entradas a la tabla de flujo (no se puede acceder a reglas de descarga de flujo ni a enlaces de tabla de flujo desde la ruta del paquete), por lo que es seguro llamar a nf_flow_table_free() que limpia las entradas restantes de la tabla de flujo (tanto de software como de hardware) y desvincula flow_block.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gso: no omita el encabezado de IP externo en caso de ipip y net_failover. Nos encontramos con un problema de caída de TCP en nuestro entorno de nube. El paquete GROed en el host se reenvía a una NIC virtio_net de VM con net_failover habilitado. VM actúa como IPVS LB con encapsulación ipip. La ruta completa como: host gro -> vm virtio_net rx -> net_failover rx -> ipvs fullnat -> ipip encap -> net_failover tx -> virtio_net tx Cuando net_failover transmite un paquete ipip (gso_type = 0x0103, que significa SKB_GSO_TCPV4, SKB_GSO_DODGY y SKB_GSO_IPXIP 4 ), no existe gso porque admite TSO y GSO_IPXIP4. Pero network_header apunta al encabezado IP interno. Seguimiento de llamadas: tcp4_gso_segment ------> return NULL inet_gso_segment ------> iph interno, network_header apunta a ipip_gso_segment inet_gso_segment ------> iph externo skb_mac_gso_segment Luego, virtio_net transmite el paquete, solo se muestra el encabezado de IP interno modificado. Y el exterior simplemente se mantiene sin cambios. El paquete se colocará en el host remoto. Seguimiento de llamadas: inet_gso_segment ------> iph interno, se omite el iph externo skb_mac_gso_segment __skb_gso_segment validar_xmit_skb validar_xmit_skb_list sch_direct_xmit __qdisc_run __dev_queue_xmit ------> virtio_net dev_hard_start_xmit __dev_queue_xmit --- ---> net_failover ip_finish_output2 ip_output iptunnel_xmit ip_tunnel_xmit ipip_tunnel_xmit -- ----> ipip dev_hard_start_xmit __dev_queue_xmit ip_finish_output2 ip_output ip_forward ip_rcv __netif_receive_skb_one_core netif_receive_skb_internal napi_gro_receiveceived_buf virtnet_poll net_rx_action La causa raíz de este problema es específica de la rara combinación de SKB_GSO_DODGY y un dispositivo de túnel que agrega una opción de túnel SKB_GSO_. SKB_GSO_DODGY se configura desde virtio_net externo. Necesitamos restablecer el encabezado de la red cuando callbacks.gso_segment() devuelve NULL. Este parche también incluye ipv6_gso_segment(), considerando SIT, etc.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: gadget: rndis: agregar spinlock para la lista de respuestas de rndis No hay bloqueo para la lista de respuestas de rndis. Podría causar corrupción en la lista si hay dos list_add diferentes al mismo tiempo, como se muestra a continuación. Es mejor agregar rndis_add_response / rndis_free_response / rndis_get_next_response para evitar cualquier condición de ejecución en la lista de respuestas. [ 361.894299] [1: irq/191-dwc3:16979] list_add corrupción. siguiente->anterior debería ser anterior (ffffff80651764d0), pero era ffffff883dc36f80. (siguiente=ffffff80651764d0). [ 361.904380] [1: irq/191-dwc3:16979] Rastreo de llamadas: [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979 ] rndis_msg_parser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] misión+0x20/0xe4 [ 361.904426] [1: irq /191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0 [ 361.904442] [1: 16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec [ 361.904465 ] [1: irq/191-dwc3: 16979] dwc3_thread_interrupt+0x34/0x5c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: tsc2046: corrige la corrupción de la memoria evitando el desbordamiento de la matriz. Por un lado tenemos indio_dev->num_channels incluye todos los canales físicos + canal de marca de tiempo. Del otro lado tenemos un array asignado sólo para canales físicos. Por lo tanto, corrija la corrupción de la memoria con ARRAY_SIZE() en lugar de la variable num_channels. Tenga en cuenta que el primer caso es una limpieza en lugar de una solución, ya que el núcleo IIO nunca establece el bit del canal de marca de tiempo del software en active_scanmask.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: men_z188_adc: corrige una fuga de recursos en una ruta de manejo de errores. Si iio_device_register() falla, un ioremap() anterior queda desequilibrado. Actualice la ruta de manejo de errores y agregue la llamada iounmap() que falta, como ya se hizo en la función de eliminación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Se corrigió el bloqueo debido al acceso fuera de los límites a reg2btf_ids. Cuando el commit e6ac2450d6de ("bpf: admite la función del kernel que llama al programa bpf") agregó soporte para kfunc, definió reg2btf_ids como una forma económica de traducir el tipo de registro del verificador al ID de BTF btf_vmlinux apropiado; sin embargo, commit c25b2ae13603 ("bpf: reemplace PTR_TO_XXX_OR_NULL con PTR_TO_XXX | PTR_MAYBE_NULL") movió __BPF_REG_TYPE_MAX del último miembro de la enumeración bpf_reg_type a después de los tipos de registro base y definió otras variantes utilizando la composición de indicadores de tipo. Sin embargo, ahora, el uso directo de reg->type para indexar en reg2btf_ids ya no puede caer en el rango __BPF_REG_TYPE_MAX y, por lo tanto, provocar un acceso fuera de los límites y un bloqueo del kernel al desreferenciar un puntero incorrecto.