Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: corrige la desreferencia del puntero NULL en la advertencia de copia. Este parche corrige una desreferencia del puntero NULL para que funcione un mensaje de advertencia introducido recientemente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rtnetlink: asegúrese de actualizar master_dev/m_ops en __rtnl_newlink() Mientras observaba un error de syzbot no relacionado, encontré la lógica de reproducción en __rtnl_newlink() para activar potencialmente el use-after-free. Es mejor borrar master_dev y m_ops dentro del bucle, en caso de que tengamos que reproducirlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: amd-xgbe: corrige el desbordamiento de longitud de datos de skb. Se activará BUG_ON() en include/linux/skbuff.h, lo que provocará un pánico intermitente en el kernel, cuando el desbordamiento de longitud de skb sea detectado. Solucione este problema descartando el paquete si se observan desbordamientos de longitud debido a inconsistencias en los descriptores de hardware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Utilice del_timer_sync en el flujo de desactivación del sondeo de reinicio de fw. Sustituya del_timer() por del_timer_sync() en el flujo de desactivación del sondeo de reinicio de fw, para evitar una condición de ejecución que se produce cuando se llama a del_timer() y el temporizador se desactiva mientras otro proceso maneja la interrupción del temporizador. Una situación que llevó al siguiente seguimiento de llamadas: RIP: 0010:run_timer_softirq+0x137/0x420 recalibrate_cpu_khz+0x10/0x10 ktime_get+0x3e/0xa0 ? sched_clock_cpu+0xb/0xc0 __do_softirq+0xf5/0x2ea irq_exit_rcu+0xc1/0xf0 sysvec_apic_timer_interrupt+0x9e/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: Se corrigió el manejo de dispositivos incorrectos durante el bond netevent. La implementación actual del controlador bond netevent solo verifica si el netdev manejado es el representante VF y falta una verificación si el representante VF está activado. el mismo dispositivo físico del vínculo que maneja el evento neto. Para solucionarlo, agregue la verificación que falta y optimice la verificación si netdev es el representante de VF para que no acceda a datos privados no inicializados y se bloquee. ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000036c PGD 0 P4D 0 Ups: 0000 [#1] Cola de trabajo SMP NOPTI: eth3bond0 bond_mii_monitor [unión] RIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core] RSP: 018:ffff88812d69fd60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000 RDX: ffff88812d69fe10 RSI: 0000000000000001b RDI: ffff8881cf800880 RBP: ffff8881 cf800000 R08: 00000445cabccf2b R09: 0000000000000008 R10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10 R13: 00000000ffffffe R 14: ffff88820c0f9000 R15: 0000000000000000 FS: 0000000000000000(0000 ) GS:ffff88846fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036c CR3: 0000000103d80 006 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 000000000000400 Llamar Seguimiento: mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core] mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core] mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core] raw_notifier_call_chain+0x41/0x60 _notifiers_info+0x34/0x80 netdev_lower_state_changed+0x4e/0xa0 bond_mii_monitor+0x56b/0x640 [vinculación] proceso_one_work +0x1b9/0x390 hilo_trabajador+0x4d/0x3d0 ? hilo_rescate+0x350/0x350 khilo+0x124/0x150 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige el desplazamiento incorrecto en bio_truncate() bio_truncate() borra el búfer fuera del último bloque de bdev, sin embargo, el bio_truncate() actual está usando el desplazamiento de página incorrecto. Entonces puede devolver los datos no inicializados. Esto sucedió cuando tanto el FS truncado/corrupto como el espacio de usuario (a través de bdev) intentaban leer lo último de bdev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Evite el desbordamiento de campos memcpy() En preparación para FORTIFY_SOURCE, se realizan comprobaciones de los límites de campos en tiempo de compilación y tiempo de ejecución para memcpy(), memmove() y memset( ), evite escribir intencionalmente en campos vecinos. Utilice matrices flexibles en lugar de matrices de elementos cero (que parecen estar siempre desbordadas) y divida el campo cruzado memcpy() en dos mitades que el compilador pueda verificar adecuadamente los límites. Estábamos haciendo: #define ETH_HLEN 14 #define VLAN_HLEN 4... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... estructura mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->datos; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); El objetivo es wqe->eth.inline_hdr.start (que el compilador considera que tiene un tamaño de 2 bytes), pero copia 18, con la intención de escribir a lo largo del inicio (en realidad, vlan_tci, 2 bytes). Los 16 bytes restantes se escriben en wqe->data[0], cubriendo byte_count (4 bytes), lkey (4 bytes) y addr (8 bytes). estructura mlx5e_tx_wqe { estructura mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg datos[]; /* 32 0 */ /* tamaño: 32, líneas de caché: 1, miembros: 3 */ /* última línea de caché: 32 bytes */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ unión { estructura { __be16 sz; /* 12 2 */ u8 inicio[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 tipo; /* 12 2 */ __be16 vlan_tci; /* 14 2 */ } insertar; /* 12 4 */ __be32 remolque; /* 12 4 */ }; /* 12 4 */ /* tamaño: 16, líneas de caché: 1, miembros: 9 */ /* última línea de caché: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 dirección; /* 8 8 */ /* tamaño: 16, líneas de caché: 1, miembros: 3 */ /* última línea de caché: 16 bytes */ }; Entonces, divida memcpy() para que el compilador pueda razonar sobre los tamaños del búfer. "pahole" no muestra cambios de tamaño ni de compensación de miembros en la estructura mlx5e_tx_wqe ni en la estructura mlx5e_umr_wqe. "objdump -d" no muestra cambios significativos en el código objeto (es decir, solo diferencias y optimizaciones inducidas por el número de línea de origen).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/ucma: protege mc durante las salidas simultáneas de multidifusión. Revierta parcialmente la confirmación mencionada en la línea Correcciones para asegurarse de que la asignación y el borrado de la estructura de multidifusión estén bloqueados. ERROR: KASAN: use-after-free en ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [en línea] ERROR: KASAN: use-after-free en ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c: 579 Lectura de tamaño 8 en la dirección ffff88801bb74b00 mediante la tarea syz-executor.1/25529 CPU: 0 PID: 25529 Comm: syz-executor.1 No contaminado 5.16.0-rc7-syzkaller #0 Nombre de 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_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan /report.c:247 __kasan_report mm/kasan/report.c:433 [en línea] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [en línea] ucma_destroy_private_ctx+0x914/0xb70 controladores/infiniband/core/ucma.c:579 ucma_destroy_id+0x1e6/0x280 controladores/infiniband/core/ucma.c:614 ucma_write+0x25c/0x350 controladores/infiniband/core/ucma.c:1732 vfs_write+ 0x28e/0xae0 fs/read_write.c:588 ksys_write+0x1ee/0x250 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common. c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae Actualmente, la búsqueda de xarray puede tocar un mc que se libera simultáneamente ya que xa_for_each() no está rodeado por ningún candado. En lugar de mantener el bloqueo durante un escaneo completo, manténgalo solo para los elementos afectados, que generalmente son una lista vacía.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: Evite consumir un valor esr obsoleto cuando ocurre un SError Cuando ocurre cualquier excepción que no sea una IRQ, la CPU actualiza el registro ESR_EL2 con el síndrome de excepción. Un SError también puede quedar pendiente y KVM lo sincronizará. KVM anota el tipo de excepción y si se sincronizó un SError en exit_code. Cuando ocurre una excepción distinta a una IRQ, fixup_guest_exit() actualiza vcpu->arch.fault.esr_el2 desde el registro de hardware. Cuando se sincroniza un SError, el valor de vcpu esr se utiliza para determinar si la excepción se debió a un HVC. Si es así, ELR_EL2 retrocede una instrucción. Esto es para que KVM pueda procesar el SError primero y volver a ejecutar el HVC si el invitado sobrevive al SError. Pero si una IRQ sincroniza un SError, el valor esr de la vcpu está obsoleto. Si la excepción anterior no IRQ era un HVC, KVM dañará ELR_EL2, lo que provocará que se ejecute dos veces una instrucción invitada no relacionada. Verifique ARM_EXCEPTION_CODE() antes de jugar con ELR_EL2, las IRQ no actualizan este registro, por lo que no es necesario verificarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/hfi1: corrige el pánico de inicio temprano de AIP Una falla temprana en hfi1_ipoib_setup_rn() puede provocar el siguiente pánico: ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 00000000000001b0 PGD 0 P4D 0 Vaya: 0002 [#1] Cola de trabajo SMP NOPTI: eventos work_for_cpu_fn RIP: 0010:try_to_grab_pending+0x2b/0x140 Código: 1f 44 00 00 41 55 41 54 55 48 89 d5 53 48 89 fb 9c 58 0f 1f 4 00 00 48 89 c2 fa 66 0f 1f 44 00 00 48 89 55 00 40 84 f6 75 77 48 0f ba 2b 00 72 09 31 c0 5b 5d 41 5c 41 5d c3 48 89 df e8 6c RSP 0018:ffffb6b3cf7 cfa48 EFLAGS: 00010046 RAX: 0000000000000246 RBX: 00000000000001b0 RCX: 0000000000000000 RDX: 0000000000000246 RSI: 00000000000000000 RDI: 00000000000001b0 RBP: ffffb6b3cf7cfa70 R08: 0000000000000f09 R09: 0000000000000001 R10: 0000000000000000 R11: 00000000000000001 R12: 0000000000000000 R13: b6b3cf7cfa90 R14: ffffffff9b2fbfc0 R15: ffff8a4fdf244690 FS: 0000000000000000(0000) GS :ffff8a527f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000001b0 CR3: CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000 0000000000400 PKRU: 55555554 Seguimiento de llamadas: __cancel_work_timer+0x42/0x190 ? dev_printk_emit+0x4e/0x70 iowait_cancel_work+0x15/0x30 [hfi1] hfi1_ipoib_txreq_deinit+0x5a/0x220 [hfi1] ? dev_err+0x6c/0x90 hfi1_ipoib_netdev_dtor+0x15/0x30 [hfi1] hfi1_ipoib_setup_rn+0x10e/0x150 [hfi1] rdma_init_netdev+0x5a/0x80 [ib_core] ? hfi1_ipoib_free_rdma_netdev+0x20/0x20 [hfi1] ipoib_intf_init+0x6c/0x350 [ib_ipoib] ipoib_intf_alloc+0x5c/0xc0 [ib_ipoib] ipoib_add_one+0xbe/0x300 [ib_ipoib] 0x1a0 [ib_core] enable_device_and_get+0xdc/0x1d0 [ib_core] ib_register_device+ 0x572/0x6b0 [ib_core] rvt_register_device+0x11b/0x220 [rdmavt] hfi1_register_ib_device+0x6b4/0x770 [hfi1] do_init_one.isra.20+0x3e3/0x680 [hfi1] local_pci_probe+0x41/0x90 cpu_fn+0x16/0x20 proceso_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 trabajador_thread+0x1cf/0x390? create_worker+0x1a0/0x1a0 kthread+0x116/0x130? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40 El pánico ocurre en hfi1_ipoib_txreq_deinit() porque hay una deref NULL cuando se llama a hfi1_ipoib_netdev_dtor() en este caso de error. hfi1_ipoib_txreq_init() y hfi1_ipoib_rxq_init() se desenrollan automáticamente, así que corrija ajustando las rutas de error en consecuencia. Otros cambios: - hfi1_ipoib_free_rdma_netdev() se elimina incluyendo free_netdev() ya que el código central de netdev elimina las llamadas free_netdev() - El cambio a las entradas aceleradas se mueve a la ruta de éxito.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/hfi1: Corrija el pánico con ipoib send_queue_size más grande Cuando ipoib send_queue_size aumenta respecto del valor predeterminado, ocurre el siguiente pánico: RIP: 0010:hfi1_ipoib_drain_tx_ring+0x45/0xf0 [hfi1] Código: 31 e4 eb 0f 8b 85 c8 02 00 00 41 83 c4 01 44 39 e0 76 60 8b 8d cc 02 00 00 44 89 e3 be 01 00 00 00 d3 e3 48 03 9d c0 02 00 00 83 8 01 00 00 00 00 00 00 48 8b bb 30 01 00 00 e8 25 af a7 e0 RSP: 0018:ffffc9000798f4a0 EFLAGS: 00010286 RAX: 00000000000008000 RBX: ffffc9000aa0f000 RCX: 000000000000000f RDX: 00000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88810ff08000 R08: ffff88889476d900 R09: 0000000000000101 R10: 0000000000000000 R11: ffffc90006590ff8 R12: 0000000000000200 R13: ffffc9000798fba8 R14: 0000000000000000 R15: 00000000000001 FS: 00007fd0f79cc3c0(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR 2: ffffc9000aa0f118 CR3 : 0000000889c84001 CR4: 00000000001706e0 Seguimiento de llamadas: hfi1_ipoib_napi_tx_disable+0x45/0x60 [hfi1] hfi1_ipoib_dev_stop+0x18/0x80 [hfi1] [ib_ipoib] ipoib_stop+0x48/0xc0 [ib_ipoib] __dev_close_many+0x9e/0x110 __dev_change_flags+ 0xd9/0x210 dev_change_flags+0x21/0x60 do_setlink+0x31c/0x10f0? __nla_validate_parse+0x12d/0x1a0 ? __nla_parse+0x21/0x30? inet6_validate_link_af+0x5e/0xf0? cpumask_next+0x1f/0x20 ? __snmp6_fill_stats64.isra.53+0xbb/0x140 ? __nla_validate_parse+0x47/0x1a0 __rtnl_newlink+0x530/0x910 ? pskb_expand_head+0x73/0x300? __kmalloc_node_track_caller+0x109/0x280 ? __nla_put+0xc/0x20 ? cpumask_next_and+0x20/0x30? update_sd_lb_stats.constprop.144+0xd3/0x820? _raw_spin_unlock_irqrestore+0x25/0x37? __wake_up_common_lock+0x87/0xc0? kmem_cache_alloc_trace+0x3d/0x3d0 rtnl_newlink+0x43/0x60 El problema ocurre cuando el cambio que debería haber sido una función del tamaño del elemento txq usó por error el tamaño del anillo. Arreglar usando el tamaño del elemento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: heaps: repara un posible gadget de Spectre v1. Parece que nr podría ser un gadget de Spectre v1, ya que lo proporciona un usuario y se utiliza como índice de matriz. Evite que el contenido de la memoria del kernel se filtre al espacio de usuario mediante ejecución especulativa utilizando array_index_nospec. [presenta: correcciones agregadas y cc: etiquetas estables]