Vulnerabilidades

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").

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: x86: corrige el acceso a la memoria de pila fuera de los límites desde ioapic_write_indirect() KASAN informa el siguiente problema: BUG: KASAN: pila fuera de los límites en kvm_make_vcpus_request_mask+ 0x174/0x440 [kvm] Lectura de tamaño 8 en la dirección ffffc9001364f638 por tarea qemu-kvm/4798 CPU: 0 PID: 4798 Comm: qemu-kvm Contaminado: GX --------- --- Nombre de hardware: AMD Corporación DAYTONA_X/DAYTONA_X, BIOS RYM0081C 13/07/2020 Seguimiento de llamadas: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x130 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] __kasan_report.cold+0x7f/0x114 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kasan_report+0x38/0x50 kasan_check_range+0xf5/0x1d0 kvm_make_vcpus_request_mask+0x174/0x440 [kvm] 0 [kvm] ? kvm_arch_exit+0x110/0x110 [kvm] ? sched_clock+0x5/0x10 ioapic_write_indirect+0x59f/0x9e0 [kvm] ? static_obj+0xc0/0xc0? __lock_acquired+0x1d2/0x8c0? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm] El problema parece ser que 'vcpu_bitmap' está asignado como un único largo en la pila y en realidad debería ser KVM_MAX_VCPUS largo. También parece que borramos los 16 bits inferiores con bitmap_zero() sin ningún motivo en particular (supongo que las variables 'bitmap' y 'vcpu_bitmap' en kvm_bitmap_or_dest_vcpus() causaron la confusión: mientras que la última tiene 16 bits de longitud , este último debería acomodar todas las vCPU posibles).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: asegúrese de que rdma_addr_cancel() ocurra antes de emitir más solicitudes. El FSM puede ejecutarse en un círculo permitiendo llamar a rdma_resolve_ip() dos veces en el mismo id_priv. Si bien esto no puede suceder sin realizar el trabajo, viola la invariante de que la misma solicitud en segundo plano de resolución de dirección no puede estar activa dos veces. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): para #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. el controlador sigue ejecutándose...] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler)!! ahora hay dos solicitudes en la lista de solicitudes rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // Process_one_req() lo elimina automáticamente spin_lock_bh(&lock); cancel_delayed_work(&req->trabajo); if (!list_empty(&req->list)) == verdadero! rdma_addr_cancel() regresa después de que se realiza el proceso_on_req #1 kfree(id_priv) Process_one_req(): para #2 addr_handler(): mutex_lock(&id_priv->handler_mutex); !! El use after free en id_priv rdma_addr_cancel() espera que haya una solicitud en la lista y solo cancela la primera. El comportamiento de autoeliminación del trabajo sólo ocurre después de que el manipulador ha regresado. Esto genera situaciones en las que req_list puede tener dos solicitudes para el mismo "identificador" pero rdma_addr_cancel() solo cancela la primera. El segundo requisito permanece activo más allá de rdma_destroy_id() y usará id_priv después de liberarlo una vez que inevitablemente se active. Solucione este problema recordando si id_priv ha llamado a rdma_resolve_ip() y cancele siempre antes de volver a llamarlo. Esto garantiza que req_list nunca obtenga más de un elemento y no cueste nada en el flujo normal que nunca utiliza esta extraña ruta de error.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/cma: corrige la fuga del oyente en el fallo de rdma_cma_listen_on_all(). Si cma_listen_on_all() falla, deja el ID por dispositivo todavía en la lista de escucha, pero el estado no está configurado en RDMA_CM_ADDR_BOUND. Cuando el cmid finalmente se destruye, no se llama a cma_cancel_listens() debido a un estado incorrecto; sin embargo, los ID por dispositivo aún mantienen el refcount evitando que el ID se destruya, lo que genera un punto muerto: tarea:rping estado:D pila: 0 pid: 19605 ppid: 47036 banderas: 0x00000084 Seguimiento de llamadas: __schedule+0x29a/0x780? free_unref_page_commit+0x9b/0x110 Schedule+0x3c/0xa0 Schedule_timeout+0x215/0x2b0? __flush_work+0x19e/0x1e0 wait_for_completion+0x8d/0xf0 _destroy_id+0x144/0x210 [rdma_cm] ucma_close_id+0x2b/0x40 [rdma_ucm] __destroy_id+0x93/0x2c0 [rdma_ucm] ? __xa_erase+0x4a/0xa0 ucma_destroy_id+0x9a/0x120 [rdma_ucm] ucma_write+0xb8/0x130 [rdma_ucm] vfs_write+0xb4/0x250 ksys_write+0xb5/0xd0 ? syscall_trace_enter.isra.19+0x123/0x190 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Asegúrese de que cma_listen_on_all() desenrolle atómicamente su acción bajo el bloqueo durante el error.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (mlxreg-fan) Devuelve un valor distinto de cero cuando el estado actual del ventilador se aplica desde sysfs. La velocidad mínima del ventilador se puede aplicar desde sysfs. Por ejemplo, configurar la velocidad actual del ventilador en 20 se utiliza para hacer que la velocidad del ventilador esté al 100 %, 19, para que no esté por debajo del 90 %, etcétera. Esta característica brinda la capacidad de limitar la velocidad del ventilador de acuerdo con algunas consideraciones del sistema, como la ausencia de algunas unidades reemplazables o la alta temperatura ambiente del sistema. La solicitud para cambiar la velocidad mínima del ventilador es una solicitud de configuración y solo se puede configurar mediante el procedimiento de escritura 'sysfs'. En esta situación, el valor del argumento "estado" está por encima de la velocidad máxima nominal del ventilador. En este caso, devuelva un código distinto de cero para evitar la llamada a Thermal_cooling_device_stats_update(), porque en este caso la actualización de estadísticas viola el rango de la tabla de estadísticas térmicas. Los problemas se observan en caso de que el kernel esté configurado con la opción CONFIG_THERMAL_STATISTICS. Aquí está el rastro de KASAN: [159.506659] ERROR: KASAN: slab fuera de los límites en Thermal_cooling_device_stats_update+0x7d/0xb0 [159.516016] Lectura de tamaño 4 en la dirección ffff888116163840 mediante la tarea hw-management.s/7444 [ 625] Llamada Seguimiento: [159.548366] dump_stack+0x92/0xc1 [159.552084]? Thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] Thermal_zone_device_update+0x345/0x780 [ 159.688711] Thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f /0x590 [mlxsw_core] [159.700972]? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core] [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core] [ 160.070233] RIP: 0033:0x7fd995909970 [ 160.07423 9] Código: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff .. [ 160.095242] RSP: 00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970 [ 160.111710] RDX: 00000000000000013 RSI: 0000000001906008 RDI: 000000000000 0001 [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700 [ 160.127687] R10: 0000000000000073 R11: 000000246 R12: 00000000000000013 [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013 [ 160.143671] [ 160.145338] Asignado por tarea 2924: [ 160.149242] x40 [ 160.153541] __kasan_kmalloc+0x7f/0xa0 [ 160.157743] __kmalloc+0x1a2/0x2b0 [ 160.161552] Thermal_cooling_device_setup_sysfs+0xf9/0x1a0 [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500 [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0 [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan] [ 160. 248140] [160.249807] La dirección con errores pertenece al objeto en ffff888116163400 [160.249807] que pertenece al caché kmalloc-1k de tamaño 1024 [ 160.263814] La dirección con errores se encuentra 64 bytes a la derecha de [ 160.263814] Región de 1024 bytes [ffff888116163400, ffff888116163800) [ 160.277536] La dirección con errores pertenece a la página: [ 160.2 82898] página:0000000012275840 refcount :1 mapcount:0 mapeo:0000000000000000 índice:0xffff888116167000 pfn:0x116160 [ 160.294872] head:0000000012275840 orden:3 compuesto_mapcount:0 compuesto_pincount:0 [ 160.303251] banderas: 00000010200(slab|cabeza|nodo=0|zona=2) [ 160.309694 ] sin formato: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0 [ 160.318367] sin formato: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000 [160.327033] página volcada porque: kasan: mal acceso detectado [160.333270] [160.334937] Estado de la memoria alrededor de la dirección con errores: [160.356469] >ffff888116163800: fc ..