Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: desvincular la tabla antes de eliminarla syzbot informa de lo sigueinte. UAF: BUG: KASAN: use-after-free en memcmp+0x18f/0x1c0 lib/string.c:955 nla_strcmp+ 0xf2/0x130 lib/nlattr.c:836 nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570 nft_table_lookup net/netfilter/nf_tables_api.c:4064 [en línea] nf_tables_getset+0x1b3/0x860 net /filtro de red/ nf_tables_api.c:4064 nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 El problema es que todas las operaciones de obtención no tienen bloqueo, por lo que el commit_mutex mantenido por () no es suficiente para evitar que una solicitud GET paralela realice accesos de lectura al objeto de la tabla incluso después de sincronizar_rcu(). Para evitar esto, primero desvincule la tabla y almacene los objetos de la tabla en el espacio temporal de la pila.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: límite inyectado de vht mcs/nss en ieee80211_parse_tx_radiotap. Limite los valores máximos para vht mcs y nss en la rutina ieee80211_parse_tx_radiotap para corregir la siguiente advertencia reportada por syzbot: ADVERTENCIA: CPU: 0 PID : 10717 en include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [en línea] ADVERTENCIA: CPU: 0 PID: 10717 en include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12 d0 neto/ mac80211/tx.c:2244 Módulos vinculados en: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01 /2011 RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [en línea] RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 86f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000ffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 000000000015 06f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000600 ieee80211_monitor_select_queue+0xa6 /0x250 net/mac80211/iface.c:740 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165 __bpf_tx_skb net/core/filter.c:2114 [ en línea] __bpf_redirect_no_mac net/core/filter.c:2139 [en línea] __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162 ____bpf_clone_redirect net/core/filter.c:2429 [en línea] bpf_clone_redirect+0x2ae/0x420 net/core /filter.c:2401 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234 bpf_dispatcher_nop_func include/linux/bpf.h:717 [en línea] __bpf_prog_run include/linux/filter.h:624 [en línea] bpf_prog_run include/linux/filter.h:631 [ en línea] bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663 bpf_prog_test_run kernel/bpf/syscall.c:3307 [en línea] 5df0 núcleo/bpf/ syscall.c:4605 __do_sys_bpf kernel/bpf/syscall.c:4691 [en línea] __se_sys_bpf kernel/bpf/syscall.c:4689 [en línea] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689 4 arco/x86/ entrada/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entrada_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211-hwsim: corrige el manejo tardío del hrtimer de baliza. Thomas explicó en https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx que nuestro manejo del hrtimer aquí es incorrecto : Si el temporizador se activa tarde (por ejemplo, debido a la programación de vCPU, según lo informado por Dmitry/syzbot), entonces intenta rearmar el temporizador en la próxima fecha límite, que podría haber sido ya en el pasado: 1 2 3 N N+1 | | | ... | | ^ intención de disparar aquí (1) ^ próxima fecha límite aquí (2) ^ realmente disparado aquí La próxima vez que se active, será más tarde, pero aún así intentará programar la próxima fecha límite (ahora 3), etc. hasta que se ponga al día N, pero eso podría llevar mucho tiempo, causando bloqueos, etc. Ahora, todo esto es simulación, así que solo tenemos que arreglarlo, pero tenga en cuenta que el comportamiento es incorrecto incluso según la especificación, ya que no tiene ningún valor enviar todos esos balizas no alineadas: deben estar alineadas con el TBTT (1, 2, 3, ... en la imagen), y si llegamos un poco (o mucho) tarde, simplemente reanudemos en ese punto. Por lo tanto, cambie el código para usar hrtimer_forward_now(), lo que garantizará que el siguiente disparo del temporizador sea en N+1 (en la imagen), es decir, el siguiente punto del intervalo después de la hora actual.