Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/hfi1: corrige la fuga del puntero del kernel. Los punteros deben imprimirse con %p o %px en lugar de convertirlos a 'unsigned long long' e imprimirse con %llx. Cambie %llx a %p para imprimir el puntero seguro.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ixgbe: corrige la desreferencia del puntero NULL en ixgbe_xdp_setup. El controlador ixgbe actualmente genera una desreferencia del puntero NULL con alguna máquina (cpus en línea <63). Esto se debe al hecho de que el valor máximo de num_xdp_queues es nr_cpu_ids. El código está en "ixgbe_set_rss_queues"". Así es como el problema se repite: alguna máquina (cpus en línea <63), y el usuario configuró num_queues en 63 a través de ethtool. El código está en "ixgbe_set_channels", adaptador->ring_feature[RING_F_FDIR].limit = count; se convierte en 63. Cuando el usuario usa xdp, "ixgbe_set_rss_queues" establecerá el número de colas adaptor->num_rx_queues = rss_i; = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit; Entonces "num_rx_queues" > "num_xdp_queues", cuando se ejecuta en "ixgbe_xdp_setup", para (i = 0; i < adaptor->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem) Genera pánico: [excepción RIP: ixgbe_xdp+368] RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000 RDX : 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90 RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000 R10: ffff9fe1620 2f830 R11: 0000000000000000 R12: ffff92f8f24c0000 R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530 ORIG_RAX: ffffffffffffffff CS: : 0018 7 [ffff9fe16202f8f0] dev_xdp_install en fffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd en fffffffa8a08808 9 [ffff9fe16202f960] do_setlink en fffffffa8a20235 10 [ffff9fe16202fa88] rtnl_setlink en fffffffa8a20384 11 [ffff9fe16202fc78] rtnetlink_rcv_msg en ffffffffa8a1a8dd 12 [ffff9fe16202fcf0] netlink_rcv_skb en ffffffffa8a717eb 13 [ffff9fe16202fd40] netlink_unicast en fffffffa8a70f88 14 [ffff9fe162 02fd80] netlink_sendmsg en fffffffa8a71319 15 [ffff9fe16202fdf0] sock_sendmsg en ffffffffa89df290 16 [ffff9fe16202fe08] __sys_sendto en ffffffffa89e19c8 17 [ffff9fe16202ff30] __x64_sys_sendto en ffffffffa89e1a64 8 [ffff9fe16202ff38] do_syscall_64 en ffffffffa84042b9 19 [ffff9fe16202ff50] Entry_SYSCALL_64_after_hwframe en ffffffffa8c0008c Entonces arreglo ixgbe_max_channels para que no permita una configuración de colas ser mayor que num_online_cpus(). Y cuando ejecute ixgbe_xdp_setup, tome el valor más pequeño de num_rx_queues y num_xdp_queues.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: no permitir llamadas repetidas a hns3_nic_net_open. No se permite llamar repetidamente a hns3_nic_net_open(), pero no se puede verificar esto. Al restablecer y configurar tc el dispositivo simultáneamente, existe una pequeña oportunidad de llamar a hns3_nic_net_open repetidamente y causar un error en el kernel al llamar a napi_enable dos veces. La información del seguimiento de llamadas es la siguiente: [3078.222780] ------------[ cortar aquí ]------------ [ 3078.230255] BUG del kernel en net/core/dev. c:6991! [3078.236224] Error interno: Ups - BUG: 0 [#1] SMP PREEMPLEADO [3078.243431] Módulos vinculados en: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880 CPU : 0 PID: 295 Comunicaciones: kworker/u8 :5 Contaminado: GO 5.14.0-rc4+ #1 [ 3078.269102] Nombre de hardware: , BIOS KpxxxFPGA 1P B600 V181 12/08/2021 [ 3078.276801] Cola de trabajo: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 0009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : 8000108abb20 [3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 00000000000 00000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: 00 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16 : ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9: ffffc816ad8885b8 [3078.387091] x8: ffff08209cfc6fb8 x7: ffff0820ac0da058 x6: ffff0820a8490344 [ 3 078.396356] x5: 0000000000000140 x4: 0000000000000003 x3: ffff08209cd76938 [3078.405365] x2: 0000000000000000 x1: 0000000000000010 x0: ffff0820abfe38a0 [3078.414657] Rastreo de llamadas: [3078.418517] +0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3 ] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] proceso_one_work+ 0x1dc/0x48c [ 3078.481888] work_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Código: c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ final de seguimiento 8ebe0340a1b0fb44 ] --- Una vez que hns3_nic_net_open() se ejecute correctamente, se borrará el indicador HNS3_NIC_STATE_DOWN. Por lo tanto, agregue la verificación de este indicador y regrese directamente cuando HNS3_NIC_STATE_DOWN no esté configurado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipack: ipoctal: corrige la fuga de información de la pila. El nombre del controlador tty también se usa después de registrar el controlador y específicamente no debe asignarse en la pila para evitar filtrar información al espacio del usuario (o activar un ups). Los controladores no deberían intentar codificar información de topología en el nombre del dispositivo tty, pero este se coló durante la preparación sin que nadie se diera cuenta y desde entonces otro controlador copió esta mala práctica. Arreglar la ABI es un tema aparte, pero esto al menos tapa el agujero de seguridad.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: sched: flower: protege fl_walk() con rcu. El parche que refactorizó fl_walk() para usar idr_for_each_entry_continue_ul() también eliminó la protección de rcu de filtros individuales que provoca el siguiente use after free. cuando el filtro se elimina simultáneamente. Se corrige fl_walk() para obtener el bloqueo de lectura de rcu mientras se itera y se toma la referencia del filtro y se libera temporalmente el bloqueo mientras se llama a la devolución de llamada arg->fn() que puede dormir. Seguimiento de KASAN: [352.773640] ============================================= ========================== [352.775041] ERROR: KASAN: use-after-free en fl_walk+0x159/0x240 [cls_flower] [352.776304] Lectura de tamaño 4 en addr ffff8881c8251480 por tarea tc/2987 [ 352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2 [ 352.778980] Nombre de hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13 .0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [352.781022] Seguimiento de llamadas: [352.781573] dump_stack_lvl+0x46/0x5a [352.782332] print_address_description.constprop.0+0x1f/0x140 [ 352.783400] ? fl_walk+0x159/0x240 [cls_flower] [ 352.784292] ? fl_walk+0x159/0x240 [cls_flower] [ 352.785138] kasan_report.cold+0x83/0xdf [ 352.785851] ? fl_walk+0x159/0x240 [cls_flower] [ 352.786587] kasan_check_range+0x145/0x1a0 [ 352.787337] fl_walk+0x159/0x240 [cls_flower] [ 352.788163] ? fl_put+0x10/0x10 [cls_flower] [ 352.789007] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [352.790102] tcf_chain_dump+0x231/0x450 [352.790878]? tcf_chain_tp_delete_empty+0x170/0x170 [352.791833]? __might_sleep+0x2e/0xc0 [ 352.792594] ? tfilter_notify+0x170/0x170 [352.793400]? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [352.794477] tc_dump_tfilter+0x385/0x4b0 [352.795262]? tc_new_tfilter+0x1180/0x1180 [352.796103]? __mod_node_page_state+0x1f/0xc0 [352.796974]? __build_skb_around+0x10e/0x130 [ 352.797826] netlink_dump+0x2c0/0x560 [ 352.798563] ? netlink_getsockopt+0x430/0x430 [352.799433]? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.800542] __netlink_dump_start+0x356/0x440 [ 352.801397] rtnetlink_rcv_msg+0x3ff/0x550 [ 352.802190] ? tc_new_tfilter+0x1180/0x1180 [352.802872]? rtnl_calcit.isra.0+0x1f0/0x1f0 [ 352.803668] ? tc_new_tfilter+0x1180/0x1180 [352.804344]? _copy_from_iter_nocache+0x800/0x800 [352.805202]? kasan_set_track+0x1c/0x30 [ 352.805900] netlink_rcv_skb+0xc6/0x1f0 [ 352.806587] ? rht_deferred_worker+0x6b0/0x6b0 [352.807455]? rtnl_calcit.isra.0+0x1f0/0x1f0 [352.808324]? netlink_ack+0x4d0/0x4d0 [352.809086]? netlink_deliver_tap+0x62/0x3d0 [352.809951] netlink_unicast+0x353/0x480 [352.810744]? netlink_attachskb+0x430/0x430 [352.811586]? __alloc_skb+0xd7/0x200 [ 352.812349] netlink_sendmsg+0x396/0x680 [ 352.813132] ? netlink_unicast+0x480/0x480 [352.813952]? __import_iovec+0x192/0x210 [352.814759]? netlink_unicast+0x480/0x480 [352.815580] sock_sendmsg+0x6c/0x80 [352.816299] ____sys_sendmsg+0x3a5/0x3c0 [352.817096] ? kernel_sendmsg+0x30/0x30 [352.817873]? __ia32_sys_recvmmsg+0x150/0x150 [ 352.818753] ___sys_sendmsg+0xd8/0x140 [ 352.819518] ? sendmsg_copy_msghdr+0x110/0x110 [352.820402]? ___sys_recvmsg+0xf4/0x1a0 [352.821110]? __copy_msghdr_from_user+0x260/0x260 [352.821934]? _raw_spin_lock+0x81/0xd0 [352.822680]? __handle_mm_fault+0xef3/0x1b20 [352.823549]? rb_insert_color+0x2a/0x270 [352.824373]? copy_page_range+0x16b0/0x16b0 [352.825209]? perf_event_update_userpage+0x2d0/0x2d0 [352.826190]? __fget_light+0xd9/0xf0 [ 352.826941] __sys_sendmsg+0xb3/0x130 [ 352.827613] ? __sys_sendmsg_sock+0x20/0x20 [352.828377]? do_user_addr_fault+0x2c5/0x8a0 [352.829184]? fpregs_assert_state_consistent+0x52/0x60 [352.830001]? exit_to_user_mode_prepare+0x32/0x160 [ 352.830845] do_syscall_64+0x35/0x80 [ 352.831445] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 352.832331] RIP: 0033:0x7f7bee973c1 7 [ ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipack: ipoctal: reparar fuga de referencia del módulo. Se tomó una referencia al módulo portador en cada apertura, pero solo se publicó una vez cuando se eliminó la referencia final a la estructura tty. Solucione este problema tomando la referencia del módulo e inicializando los datos del controlador tty al instalar el tty.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: betop: corrige escritura slab-out-of-bounds en betop_probe. Syzbot informó un error de escritura slab-out-of-bounds en el controlador hid-betopff. El problema es que el controlador supone que el dispositivo debe tener un informe de entrada, pero algunos dispositivos maliciosos violan esta suposición. Entonces, este parche verifica que la entrada de hid_device no esté vacía antes de usarse.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (w83792d) Corrija la desreferencia del puntero NULL eliminando el campo de estructura innecesario. Si el controlador lee el valor val suficiente para (val & 0x08) && (!(val & 0x80)) && (( val & 0x7) == ((val >> 4) & 0x7)) desde el dispositivo, luego se produce la desreferencia del puntero null. (Es posible si tmp = 0b0xyz1xyz, donde los mismos literales significan los mismos números) Además, lm75[] ya no sirve para nada después de cambiar a devm_i2c_new_dummy_device() en w83791d_detect_subclients(). El parche corrige la posible desreferencia del puntero NULL eliminando lm75[]. Encontrado por el proyecto de verificación de controladores de Linux (linuxtesting.org). [groeck: Se eliminaron líneas de continuación innecesarias, se corrigió la alineación multilínea]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (w83791d) Corrija la desreferencia del puntero NULL eliminando el campo de estructura innecesario. Si el controlador lee el valor val suficiente para (val & 0x08) && (!(val & 0x80)) && (( val & 0x7) == ((val >> 4) & 0x7)) desde el dispositivo, luego se produce la desreferencia del puntero null. (Es posible si tmp = 0b0xyz1xyz, donde los mismos literales significan los mismos números) Además, lm75[] ya no sirve para nada después de cambiar a devm_i2c_new_dummy_device() en w83791d_detect_subclients(). El parche corrige la posible desreferencia del puntero NULL eliminando lm75[]. Encontrado por el proyecto de verificación de controladores de Linux (linuxtesting.org). [groeck: Se eliminaron líneas de continuación innecesarias, se corrigió la alineación de varias líneas]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: schedutil: utilice el método kobject release() para liberar sugov_tunables. La estructura sugov_tunables está protegida por kobject, por lo que no podemos liberarla directamente. De lo contrario, obtendríamos un seguimiento de llamada como este: ODEBUG: activo libre (estado activo 0) tipo de objeto: timer_list sugerencia: delay_work_timer_fn+0x0/0x30 ADVERTENCIA: CPU: 3 PID: 720 en lib/debugobjects.c:505 debug_print_object+0xb8/ 0x100 Módulos vinculados en: CPU: 3 PID: 720 Comm: a.sh Contaminado: GW 5.14.0-rc1-next-20210715-yocto-standard+ #507 Nombre del hardware: Placa Marvell OcteonTX CN96XX (DT) pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc: debug_print_object+0xb8/0x100 lr: debug_print_object+0xb8/0x100 sp: ffff80001ecaf910 x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: d80 x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000 x23: ffff80001142aa68 x22 : ffff800011043d80 x21: ffff00010de46f20 x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010 x17: 6e6968207473696c x16: 656d6974203a x15: 6570797420746365 x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69 x11: ffff8000124b1560 x10: 0012331520 x9: ffff8000100ca6b0 x8: 000000000017ffe8 x7: c0000000fffeffff x6: 0000000000000001 x5: ffff800011d8c000 x4: ffff800011d8c740 x3: 0000000000000000 x2: ffff0001108301c0 x1: ab3c90eedf9c0f00 x0: 0000000000000000 Rastreo de llamadas: xb8/0x100 __debug_check_no_obj_freed+0x1c0/0x230 debug_check_no_obj_freed+0x20/0x88 slab_free_freelist_hook+0x154/0x1c8 kfree+0x114/0x5d0 sugov_exit+0xbc/ 0xc0 cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x268/0x4a8 store_scaling_governor+0xe0/0x128 store+0xc0/0xf0 sysfs_kf_write+0x54/0x80 kernfs_fop_write_iter+0x128/0x1c0 nuevo _sync_write+0xf0/0x190 vfs_write+0x2d4/0x478 ksys_write+0x74/0x100 __arm64_sys_write+0x24/ 0x30 invoke_syscall.constprop.0+0x54/0xe0 do_el0_svc+0x64/0x158 el0_svc+0x2c/0xb0 el0t_64_sync_handler+0xb0/0xb8 el0t_64_sync+0x198/0x19c sello de evento irq: 5518 hardirqs habilitado por última vez en ( 5517): [] consola_unlock+ 0x554/0x6c8 hardirqs deshabilitado por última vez en (5518): [] el1_dbg+0x28/0xa0 softirqs habilitado por última vez en (5504): [] __do_softirq+0x4d0/0x6c0 softirqs deshabilitado por última vez en (5483): ff800010049548 >] irq_exit+0x1b0/0x1b8 Entonces divida el sugov_tunables_free() original en dos funciones, sugov_clear_global_tunables() solo se usa para borrar los global_tunables y el nuevo sugov_tunables_free() se usa como kobj_type::release para liberar los sugov_tunables de forma segura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: corrige el use after free en CCMP/GCMP RX. Cuando se realiza la verificación de PN en mac80211, para la fragmentación necesitamos copiar el PN a la estructura RX para poder usarlo más tarde. para hacer una comparación, desde la confirmación bf30ca922a0c ("mac80211: verifique la desfragmentación PN con el marco actual"). Desafortunadamente, en esa confirmación utilicé la variable 'hdr' sin que fuera necesariamente válida, por lo que podría ocurrir un use after free si fuera necesario reasignar (partes de) el marco. Solucione este problema recargando la variable después del código que da como resultado las reasignaciones, si corresponde. Esto corrige https://bugzilla.kernel.org/show_bug.cgi?id=214401.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: corrige la falta de sev_decommission en sev_receive_start DESCOMMISSION el contexto SEV actual si falla la vinculación de un ASID después de RECEIVE_START. Según la API SEV de AMD, RECEIVE_START genera un nuevo contexto de invitado y, por lo tanto, debe combinarse con DECOMMISSION: el comando RECEIVE_START es el único comando, además del comando LAUNCH_START, que genera un nuevo contexto de invitado y un identificador de invitado. La DESCOMISIÓN faltante puede provocar fallas de inicio de SEV posteriores, ya que el firmware pierde memoria y es posible que no pueda asignar más contextos de invitados de SEV en el futuro. Tenga en cuenta que LAUNCH_START sufrió el mismo error, pero se solucionó previamente mediante la confirmación 934002cd660b ("KVM: SVM: llame a SEV Guest Decommission si falla el enlace ASID").