Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nexthop: corrige pérdidas de memoria en los oyentes de la cadena de notificaciones de nexthop syzkaller descubrió pérdidas de memoria [1] que se pueden reducir a los siguientes comandos: # ip nexthop add id 1 blackhole # devlink dev reload pci /0000:06:00.0 Como parte del flujo de recarga, mlxsw cancelará el registro de sus netdevs y luego cancelará el registro de la cadena de notificación de nexthop. Antes de cancelar el registro de la cadena de notificaciones, mlxsw recibirá notificaciones de eliminación de objetos de nexthop utilizando netdevs registrados por mlxsw o sus superiores. mlxsw no recibirá notificaciones de nexthops que utilicen netdevs que no estén desmantelados como parte del flujo de recarga. Por ejemplo, el blackhole nexthop anterior que utiliza internamente el loopback netdev como su dispositivo nexthop. Una forma de solucionar este problema es hacer que los oyentes vacíen sus tablas de nexthop después de darse de baja de la cadena de notificaciones. Esto es propenso a errores, como lo demuestra este parche, y tampoco es simétrico con la ruta de registro donde un oyente recibe un volcado de todos los nexthops existentes. Por lo tanto, solucione este problema reproduciendo las notificaciones de eliminación del oyente que se está cancelando el registro. Esto es simétrico a la ruta de registro y también consistente con la cadena de notificación de netdev. Lo anterior significa que unregister_nexthop_notifier(), al igual que Register_nexthop_notifier(), tendrá que tomar RTNL para poder iterar sobre los nexthops existentes y que cualquier persona que llame a la función no puede mantener RTNL. Esto es cierto para mlxsw y netdevsim, pero no para el controlador VXLAN. Para evitar un punto muerto, cambie este último para cancelar el registro de su oyente nexthop sin mantener presionado RTNL, haciéndolo simétrico a la ruta de registro. [1] objeto sin referencia 0xffff88806173d600 (tamaño 512): comm "syz-executor.0", pid 1290, jiffies 4295583142 (edad 143.507s) volcado hexadecimal (primeros 32 bytes): 41 9d 1e 60 80 88 ff ff 08 d6 73 1 80 88 ff ff A..`......sa.... 08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00 ..sa............ backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [en línea] [] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522 [] mm/slub.c:3206 [en línea] [] slab_alloc mm/slub.c:3214 [en línea] [] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231 [] kmalloc include/linux/slab.h: 591 [en línea] [] kzalloc include/linux/slab.h:721 [en línea] [] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [ ] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [en línea] [] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:523 9 [] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83 [] blocking_notifier_call_chain kernel/notifier.c:318 [en línea] [] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306 [] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244 [] insert_nexthop net/ipv4/nexthop.c:2336 [en línea] [] nexthop_add net/ipv4/nexthop.c:2644 [en línea] [] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913 [] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572 [ ] netlink_rcv_skb+0x173/0x480 neto/ netlink/af_netlink.c: 2504 [] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c: 5590 [] netlink_unicast_kernel net/netlink/af_fffffff.c: 1314 [faff. 6069de>] netlink_unicast +0x5ae/0x7f0 net/netlink/af_netlink.c:1340 [] --- truncado--

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macb: corrige el use after free en rmmod plat_dev->dev->platform_data es publicado por platform_device_unregister(), el uso de pclk y hclk es un use after free. Dado que la cancelación del registro del dispositivo no necesitará un dispositivo clk, ajustamos la secuencia de llamada a la función para solucionar este problema. [31.261225] ERROR: KASAN: use after free en macb_remove+0x77/0xc6 [macb_pci] [31.275563] Liberado por la tarea 306: [30.276782] platform_device_release+0x25/0x80

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v3-its: soluciona una posible fuga de VPE en caso de error. En its_vpe_irq_domain_alloc, cuando its_vpe_init() devuelve un error, hay un error de uno en uno en el número de VPE. para ser liberado. Solucionelo simplemente pasando el número de VPE asignados, que es el índice del bucle que se itera sobre los VPE. [maz: mensaje de confirmación fijo]