Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: corrige la corrupción del flujo de datos Maxim informó varios problemas al forzar a un proxy transparente TCP a utilizar el protocolo MPTCP para las conexiones entrantes. También proporcionó un reproductor limpio. El problema se reduce a 'mptcp_frag_can_collapse_to()' suponiendo que sólo MPTCP utilizará el page_frag dado. Si otros (por ejemplo, el protocolo TCP simple) asignan fragmentos de página, podemos terminar reutilizando la memoria ya asignada para mptcp_data_frag. Solucione el problema asegurándose de que el fragmento de datos que se va a expandir esté ubicado al final del fragmento de la página actual. v1 -> v2: - se agregó la etiqueta de correcciones faltantes (Mat)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: se soluciona un problema de use-after-free que parece que nos olvidamos de configurar ttm->sg en NULL. Se produce pánico a continuación [1235.844104] falla de protección general, probablemente para la dirección no canónica 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [1235.989074] Seguimiento de llamadas: [1235.991751] sg_free_table+0x17/0x20 [ 123 5.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa 0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 123 6.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [ amdgpu]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: agrega comprobaciones de puntero NULL al liberar irqs. Al liberar bloques de notificaciones, indexamos priv->msix_vectors. Si no pudimos asignar priv->msix_vectors (consulte abort_with_msix_vectors), esto podría provocar una desreferencia del puntero NULL si el controlador está descargado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no haga ERROR_ON en link_to_fixup_dir Mientras realizaba pruebas de inyección de errores, obtuve el siguiente ERROR de pánico en el kernel en fs/btrfs/tree-log.c:1862. código de operación no válido: 0000 [#1] SMP NOPTI CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 01/04/2014 RIP: 0010:link_to_fixup_dir+0xd5/0xe0 RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216 RAX: fffffffffffffffb RBX: 00000000ffffffffb RCX: ffff8f595287faf0 RDX : ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000 RBP: ffff8f5953af9450 R08: 00000000000000019 R09: 0000000000000001 R10 : 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800 R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065 FS: 00007 fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc5287f47c0 CR3: 0 00000011275e002 CR4: 0000000000370ee0 Seguimiento de llamadas: replay_one_buffer+0x409/0x470? btree_read_extent_buffer_pages+0xd0/0x110 walk_up_log_tree+0x157/0x1e0 walk_log_tree+0xa6/0x1d0 btrfs_recover_log_trees+0x1da/0x360 ? replay_one_extent+0x7b0/0x7b0 open_ctree+0x1486/0x1720 btrfs_mount_root.cold+0x12/0xea ? __kmalloc_track_caller+0x12f/0x240 Legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 ? vfs_parse_fs_string+0x4d/0x90 Legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 path_mount+0x433/0xa10 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x3d/0x80 Entry_SYSCALL_64_after_hwframe+0 x44/0xae Podemos obtener -EIO o cualquier número de errores legítimos de btrfs_search_slot() , entrar en pánico aquí no es la respuesta adecuada. La ruta de error para este código maneja los errores correctamente, simplemente devuelve el error.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: eliminar dispositivo de smcd_dev_list después de fallar device_add() Si falla el dispositivo_add() para smcd_dev, no hay ningún paso de limpieza que revierta el list_add() anterior. Posteriormente, el dispositivo se libera y terminamos con una lista corrupta. Agregue algún manejo de errores que elimine el dispositivo de la lista.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: posponga la llamada a Register_netdev() hasta que se complete la inicialización del cliente. Actualmente, el netdevice se registra antes de que se complete la inicialización del cliente. Por lo tanto, existe una ventana de tiempo entre el dispositivo de red disponible y utilizable. En este caso, si el usuario intenta cambiar el número de canal o el parámetro de timbre, puede provocar que se llame dos veces a hns3_set_rx_cpu_rmap() y se informe del error. [47199.416502] hns3 0000:35:00.0 eth1: configurar canales: tqp_num=1, rxfh=0 [47199.430340] hns3 0000:35:00.0 eth1: ya no inicializado [47199.438554] hns3 0000:35:00.0 : rss cambia de 4 a 1 [47199.511854] hns3 0000:35:00.0: Canales cambiados, rss_size de 4 a 1, tqps de 4 a 1 [47200.163524] ------------[ cortar aquí ]------- ----- ¡ERROR del kernel [47200.171674] en lib/cpu_rmap.c:142! [47200.177847] Error interno: Ups - ERROR: 0 [#1] SMP PREEMPT [47200.185259] Módulos vinculados en: hclge(+) hns3(-) hns3_cae(O) hns_roce_hw_v2 hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv68 0_mii(O) [última descarga: HCLGE] [47200.205912] CPU: 1 PID: 8260 Comm: EthTool Tainted: Go 5.11.0 -RC3 + #1 [47200.215601] Nombre de hardware:, xxxxxx 02/04/2021 [47200.223052] Pstate: 60400009 (NZCV + PAN + PANEFI. -TCO BTYPE=--) [47200.230188] pc: cpu_rmap_add+0x38/0x40 [47200.237472] lr: irq_cpu_rmap_add+0x84/0x140 [47200.243291] sp: ffff800010e93a30 [47200.247 295] x29: ffff800010e93a30 x28: ffff082100584880 [47200.254155] x27: 0000000000000000 x26: 0000000000000000 [47200.260712] x25: 0000000000000000 x24: 0000000000000004 [47200.267241] x23: ffff08209ba03000 x22: ffff08209ba038c0 [ 47200.273789] x21: 000000000000003f x20: ffff0820e2bc1680 [47200.280400] x19: ffff0820c970ec80 x18: 00000000000000c0 [47200.286944] x17: 0 000000000000000 x16: ffffb43debe4a0d0 [47200.293456] x15 : ffffc2082990600 x14: muerto000000000122 [47200.300059] x13: ffffffffffffffff x12: 000000000000003e [47200.306606] x11: ffff0820815b8080 x10: ffff53e4 11988000 [47200.313171] x9: 00000000000000000 x8: ffff0820e2bc1700 [47200.319682] x7: 00000000000000000 x6: 000000000000003f [47200.32617 0] x5: 0000000000000040 x4: ffff800010e93a20 [47200.332656] x3: 0000000000000004 x2: ffff0820c970ec80 [47200.339168] x1: ffff0820e2bc1680 x0: 00000000000000004 [47200.346058] Rastreo de llamadas: [4720 0.349324] cpu_rmap_add+0x38/0x40 [47200.354300] hns3_set_rx_cpu_rmap+0x6c/0xe0 [hns3] [47200.362294] hns3_reset_notify_init_enet+0x1cc/ 0x340 [hns3] [47200.370049] hns3_change_channels+0x40/0xb0 [hns3] [47200.376770] hns3_set_channels+0x12c/0x2a0 [hns3] [47200.383353] ethtool_set_channels+0x140/0x250 [ 47200.389772] dev_ethtool+0x714/0x23d0 [47200.394440] dev_ioctl+0x4cc/0x640 [47200.399277] sock_do_ioctl+0x100/0x2a0 [47200.404574] sock_ioctl+0x28c/0x470 [47200.409079] __arm64_sys_ioctl+0xb4/0x100 [47200.415217] el0_svc _common.constprop.0+0x84/0x210 [47200.422088] do_el0_svc+0x28/0x34 [47200.426387] el0_svc+0x28 /0x70 [47200.431308] el0_sync_handler+0x1a4/0x1b0 [47200.436477] el0_sync+0x174/0x180 [47200.441562] Código: 11000405 79000c45 f8247861 d65f03c0 (d4210 000) [47200.448869] ---[ end trace a01efe4ce42e5f34 ]--- El proceso es el siguiente: ejecutando hns3_client_init | registrarse_netdev() | hns3_set_channels() | | hns3_set_rx_cpu_rmap() hns3_reset_notify_uninit_enet() | | | salir sin llamar a la función | hns3_free_rx_cpu_rmap para bandera | HNS3_NIC_STATE_INITED no está configurado. | | | hns3_reset_notify_init_enet() | | set HNS3_NIC_STATE_INITED call hns3_set_rx_cpu_rmap()-- crash Solucionarlo llamando a Register_netdev() al final de la función hns3_client_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxgb4: evita acceder a los registros al borrar los filtros El registro de hardware que tiene la base TID del servidor puede contener valores no válidos cuando el adaptador está en mal estado (por ejemplo, debido a un error fatal de AER). Leer estos valores no válidos en el registro puede provocar un acceso a la memoria fuera de límites. Por lo tanto, solucione el problema utilizando la base TID del servidor guardado al borrar los filtros.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: lantiq: corrige la corrupción de la memoria en el anillo RX En una situación en la que falla la asignación de memoria o el mapeo dma, se programa una dirección no válida en el descriptor. Esto puede provocar daños en la memoria. Si la asignación de memoria falla, DMA debería reutilizar el skb y el mapeo anteriores y descartar el paquete. Este parche también incrementa el contador de caídas de rx.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/amd: borra las operaciones de DMA al cambiar de dominio. Desde el commit 08a27c1c3ecf ("iommu: agrega soporte para cambiar el dominio predeterminado de un grupo iommu"), un usuario puede cambiar un dispositivo entre IOMMU y DMA directo a través de sysfs. Esto no funciona para AMD IOMMU en este momento porque dev->dma_ops no se borra al cambiar de un DMA a un dominio IOMMU de identidad. Por lo tanto, la capa DMA intenta utilizar las operaciones dma-iommu en un dominio de identidad, lo que provoca un error: # echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/unbind # echo Identity > /sys/ bus/pci/devices/0000:00:05.0/iommu_group/type # echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/bind ... ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000028 ... Seguimiento de llamadas: iommu_dma_alloc e1000e_setup_tx_resources e1000e_open Dado que iommu_change_dev_def_domain() llama a probe_finalize() nuevamente, borre dma_ops allí como lo hace Vt-d.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/amdgpu: corrige la fuga de refcount [Por qué] el objeto gema rfb->base.obj[0] se obtiene según num_planes en amdgpufb_create, pero no se coloca según num_planes en amdgpufb_create num_planes [Cómo] poner rfb->base.obj[0] en amdgpu_fbdev_destroy según num_planes

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: inicialización cero de la extensión tc skb en la asignación La función skb_ext_add() no inicializa la extensión skb creada con ningún valor y lo deja en manos del usuario. Sin embargo, dado que la extensión de tipo TC_SKB_EXT originalmente contenía solo un valor único tc_skb_ext->chain, sus usuarios solían asignar simplemente el valor de la cadena sin establecer primero toda la memoria de extensión en cero. Esta suposición cambió cuando la extensión TC_SKB_EXT se amplió con campos adicionales, pero no todos los usuarios se actualizaron para inicializar los nuevos campos, lo que lleva al uso de memoria no inicializada posteriormente. Registro de UBSAN: [778.299821] UBSAN: carga no válida en net/openvswitch/flow.c:899:28 [778.301495] la carga del valor 107 no es un valor válido para el tipo '_Bool' [778.303215] CPU: 0 PID: 0 Comm : swapper/0 Not tainted 5.12.0-rc7+ #2 [ 778.304933] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/ 2014 [778.307901] Seguimiento de llamadas: [778.308680] [778.309358] dump_stack+0xbb/0x107 [778.310307] ubsan_epilogue+0x5/0x40 [778.311167] __ubsan_handle_load_invalid_value.col d+0x43/0x48 [778.312454]? memset+0x20/0x40 [778.313230] ovs_flow_key_extract.cold+0xf/0x14 [openvswitch] [778.314532] ovs_vport_receive+0x19e/0x2e0 [openvswitch] [778.315749]? ovs_vport_find_upcall_portid+0x330/0x330 [openvswitch] [778.317188]? create_prof_cpu_mask+0x20/0x20 [778.318220]? arch_stack_walk+0x82/0xf0 [778.319153]? second_startup_64_no_verify+0xb0/0xbb [778.320399]? stack_trace_save+0x91/0xc0 [778.321362]? stack_trace_consume_entry+0x160/0x160 [778.322517]? lock_release+0x52e/0x760 [778.323444] netdev_frame_hook+0x323/0x610 [openvswitch] [778.324668]? ovs_netdev_get_vport+0xe0/0xe0 [openvswitch] [778.325950] __netif_receive_skb_core+0x771/0x2db0 [778.327067]? lock_downgrade+0x6e0/0x6f0 [778.328021]? lock_acquire+0x565/0x720 [778.328940]? generic_xdp_tx+0x4f0/0x4f0 [778.329902]? inet_gro_receive+0x2a7/0x10a0 [778.330914]? lock_downgrade+0x6f0/0x6f0 [778.331867]? udp4_gro_receive+0x4c4/0x13e0 [778.332876]? lock_release+0x52e/0x760 [778.333808]? dev_gro_receive+0xcc8/0x2380 [778.334810]? lock_downgrade+0x6f0/0x6f0 [ 778.335769] __netif_receive_skb_list_core+0x295/0x820 [ 778.336955] ? proceso_backlog+0x780/0x780 [778.337941]? mlx5e_rep_tc_netdevice_event_unregister+0x20/0x20 [mlx5_core] [778.339613]? seqcount_lockdep_reader_access.constprop.0+0xa7/0xc0 [778.341033]? kvm_clock_get_cycles+0x14/0x20 [ 778.342072] netif_receive_skb_list_internal+0x5f5/0xcb0 [ 778.343288] ? __kasan_kmalloc+0x7a/0x90 [778.344234]? mlx5e_handle_rx_cqe_mpwrq+0x9e0/0x9e0 [mlx5_core] [778.345676]? mlx5e_xmit_xdp_frame_mpwqe+0x14d0/0x14d0 [mlx5_core] [778.347140]? __netif_receive_skb_list_core+0x820/0x820 [778.348351]? mlx5e_post_rx_mpwqes+0xa6/0x25d0 [mlx5_core] [778.349688]? napi_gro_flush+0x26c/0x3c0 [ 778.350641] napi_complete_done+0x188/0x6b0 [ 778.351627] mlx5e_napi_poll+0x373/0x1b80 [mlx5_core] [ 778.352853] __napi_poll+0x9f/0x510 [778.353704] ? mlx5_flow_namespace_set_mode+0x260/0x260 [mlx5_core] [778.355158] net_rx_action+0x34c/0xa40 [778.356060]? napi_threaded_poll+0x3d0/0x3d0 [778.357083]? sched_clock_cpu+0x18/0x190 [778.358041]? __common_interrupt+0x8e/0x1a0 [ 778.359045] __do_softirq+0x1ce/0x984 [ 778.359938] __irq_exit_rcu+0x137/0x1d0 [ 778.360865] irq_exit_rcu+0xa/0x20 [ 778.36170 8] interrupción_común+0x80/0xa0 [ 778.362640] [ 778.363212] asm_interrupción_común+0x1e /0x40 [ 778.364204] RIP: 0010:native_safe_halt+0xe/0x10 [ 778.365273] Código: 4f ff ff ff 4c 89 e7 e8 50 3f 40 fe e9 dc fe ff ff 48 89 df e8 43 3f 40 fe eb 90 cc e 9 07 00 00 00 0f 00 2d 74 05 62 00 fb f4 90 e9 07 00 00 00 0f 00 2d 64 05 62 00 f4 c3 cc cc 0f 1f 44 00 [ 778.369355] RSP: 0018:ffffffff84407 e48 EFLAGS: 00000246 [778.370570] RAX ---truncado---

Anope anterior a 2.0.15 no impide restablecer la contraseña de una cuenta suspendida.