Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-mq: Se corrige kmemleak en blk_mq_init_allocated_queue Hay una kmemleak causada por modprobe null_blk.ko objeto no referenciado 0xffff8881acb1f000 (tamaño 1024): comm "modprobe", pid 836, jiffies 4294971190 (edad 27.068s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] hacer_una_llamada_inicio+0xd0/0x4f0 [<00000000b389383b>] hacer_módulo_inicio+0x1a4/0x680 [<0000000087cf3542>] cargar_módulo+0x6249/0x7110 [<00000000beba61b8>] __hacer_módulo_finit_sys+0x140/0x200 [<00000000fdcfff51>] hacer_llamada_al_sistema_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Esto se debe a que q->ma_ops se establece en NULL antes de llamar a blk_release_queue. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs para (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); si (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] si (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx falló en i != 0. [2]: Los hctxs asignados por [1] se mueven a q->unused_hctx_list y se limpiarán en blk_mq_release. [3]: q->nr_hw_queues es 0. [4]: Establece q->mq_ops en NULL. [5]: queue_is_mq devuelve falso debido a [4]. No se llamará a blk_mq_release. Los hctxs en q->unused_hctx_list tienen fugas. Para solucionarlo, llame a blk_release_queue en la ruta de excepción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/region: Se corrige la fuga de cxl_region y se limpian los objetivos al eliminar una región. Al eliminar una región, todos los objetivos previamente asignados a ella contienen referencias a ella. Para eliminar esas referencias, desvincula todos los objetivos durante la ejecución de unregister_region(). De lo contrario, el objeto de región se filtrará, ya que el espacio de usuario ha perdido la capacidad de desvincular objetivos una vez que se desmantela el sistema operativo de la región.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el mal manejo del registro de mod de árbol de nodos reasignados ¡Hemos estado viendo el siguiente ERROR de pánico en el kernel de producción en fs/btrfs/tree-mod-log.c:677! código de operación no válido: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 00000000000000000 R10: 0000000000000000 R11: 00000000000100c40 R12: 000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Rastreo de llamadas: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); Esto ocurre porque reproducimos los nodos en el orden en que sucedieron, y cuando hacemos un REPLACE registraremos un REMOVE_WHILE_FREEING para cada ranura, comenzando en 0. 'n' aquí es el número de elementos en este bloque, que en este caso era 1, pero teníamos 2 operaciones REMOVE_WHILE_FREEING. La causa raíz real de esto fue que estábamos reproduciendo operaciones para un bloque que no debería haberse reproducido. Considere la siguiente secuencia de eventos: 1. Tenemos una raíz ya modificada y ejecutamos btrfs_get_tree_mod_seq(). 2. Comenzamos a eliminar elementos de esta raíz, activando KEY_REPLACE para sus ranuras secundarias. 3. Eliminamos uno de los dos hijos a los que apunta este nodo raíz, lo que activa la promoción del hijo restante y libera este nodo. 4. Modificamos una nueva raíz y reasignamos el nodo anterior al nodo raíz de esta otra raíz. El registro de mod del árbol se parece a esto lógico 0 op KEY_REPLACE (ranura 1) seq 2 lógico 0 op KEY_REMOVE (ranura 1) seq 3 lógico 0 op KEY_REMOVE_WHILE_FREEING (ranura 0) seq 4 lógico 4096 op LOG_ROOT_REPLACE (antiguo lógico 0) seq 5 lógico 8192 op KEY_REMOVE_WHILE_FREEING (ranura 1) seq 6 lógico 8192 op KEY_REMOVE_WHILE_FREEING (ranura 0) seq 7 lógico 0 op LOG_ROOT_REPLACE (antiguo lógico 8192) seq 8 >A partir de aquí el error se activa con los siguientes pasos 1. Llama a btrfs_get_old_root() en new_root. 2. Llamamos a tree_mod_log_oldest_root(btrfs_root_node(new_root)), que actualmente tiene un valor lógico 0. 3. tree_mod_log_oldest_root() llama a tree_mod_log_search_oldest(), que nos proporciona la secuencia KEY_REPLACE 2. Dado que no es un LOG_ROOT_REPLACE, creemos erróneamente que no tenemos una raíz antigua, ya que esperamos que el cambio más reciente sea un LOG_ROOT_REPLACE. 4. En tree_mod_log_oldest_root(), no tenemos un LOG_ROOT_REPLACE, por lo que no establecemos old_root; simplemente usamos nuestra e ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscrypt: dejar de usar el subsistema de llaveros para fscrypt_master_key. El enfoque de fs/crypto/, que gestionaba internamente las estructuras fscrypt_master_key como payloads de objetos "struct key" contenidos en un llavero "struct key", ha dejado de ser útil. La idea original era simplificar el código reutilizando código del subsistema de llaveros. Sin embargo, han surgido varios problemas que no se pueden resolver fácilmente: - Cuando se destruye una estructura de clave maestra, se debe llamar a blk_crypto_evict_key() en cualquier clave por modo incrustada en ella. (Esto empezó a ocurrir cuando se añadió la compatibilidad con el cifrado en línea). Sin embargo, el subsistema de llaveros puede retrasar arbitrariamente la destrucción de claves, incluso después de que se desmontara el sistema de archivos. Por lo tanto, actualmente no hay una forma sencilla de llamar a blk_crypto_evict_key() cuando se destruye una clave maestra. Actualmente, esto se soluciona manteniendo una referencia adicional a las colas de solicitudes (solicitudes) del sistema de archivos. Sin embargo, se pasó por alto que la referencia a la cola de solicitudes *no* garantiza que también fije el perfil blk_crypto_profile correspondiente; para los dispositivos con mapeador de dispositivos que admiten criptografía en línea, no lo hace. Esto puede causar un uso después de la liberación. - Cuando se expulsa el último inodo que usaba una clave maestra eliminada de forma incompleta, la eliminación de la clave maestra se completa eliminando la estructura de la clave del anillo de claves. Actualmente, esto se realiza mediante key_invalidate(). Sin embargo, key_invalidate() toma el semáforo de la clave. Esto puede generar un bloqueo al ser llamado desde el reductor, ya que en fscrypt_ioctl_add_key(), la memoria se asigna con GFP_KERNEL bajo el mismo semáforo. En términos más generales, el hecho de que el subsistema de llaveros pueda retrasar arbitrariamente la destrucción de claves (mediante un retraso en la recolección de basura o mediante procesos aleatorios que obtienen referencias temporales a las claves) es indeseable, ya que significa que no podemos garantizar estrictamente que todos los secretos se borren. Realizar las búsquedas de la clave maestra a través del subsistema de llaveros resulta en la llamada al gancho LSM key_permission. fscrypt no desea esto, ya que todo el control de acceso a los archivos cifrados está diseñado para realizarse a través de los propios archivos, como cualquier otro archivo. La solución alternativa que utilizan los usuarios de SELinux es cambiar su política de SELinux para otorgar acceso de búsqueda de claves a todos los dominios. Esto funciona, pero es un paso adicional extraño que realmente no debería ser necesario. La solución para todos estos problemas es cambiar la implementación a lo que debería haber hecho originalmente: no usar el subsistema de llaveros para realizar un seguimiento de las estructuras fscrypt_master_key del sistema de archivos. En su lugar, simplemente almacénelos en una estructura de datos de kernel normal y modifique el recuento de referencias, el bloqueo y la duración según corresponda. Mantenga la compatibilidad con las búsquedas de claves en modo RCU mediante una tabla hash. Reemplace fscrypt_sb_free() por fscrypt_sb_delete(), que libera las claves sincrónicamente y se ejecuta un poco antes durante el desmontaje, para que los dispositivos de bloque sigan disponibles. Un efecto secundario de este parche es que ni las claves maestras ni los conjuntos de claves del sistema de archivos aparecerán en /proc/keys. (Los "usuarios de clave maestra" y los conjuntos de claves de los usuarios de clave maestra seguirán apareciendo). Sin embargo, esto era principalmente un detalle de implementación y estaba destinado únicamente a fines de depuración. No conozco a nadie que lo use. Este parche *no* cambia el funcionamiento de los "usuarios de clave maestra" (->mk_users)--- truncado ----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/pmem: Arregla la fuga de cxl_pmem_region y cxl_memdev Cuando un objeto cxl_nvdimm pasa por un evento ->remove() (dispositivo eliminado físicamente, nvdimm-bridge deshabilitado o dispositivo nvdimm deshabilitado), entonces cualquier región asociada también debe deshabilitarse. Como se destaca en la prueba cxl-create-region.sh [1], un solo dispositivo puede albergar múltiples regiones, pero el controlador solo rastreaba una región a la vez. Esto lleva a una situación en la que solo la última región habilitada por dispositivo nvdimm se limpia correctamente. Se filtran otras regiones, y esto también causa fugas de referencia de cxl_memdev. Arregla el rastreo permitiendo que los objetos cxl_nvdimm rastreen múltiples asociaciones de regiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/region: Fix decoder assignment crash Cuando los decodificadores de un puerto intermedio han sido agotados por las regiones existentes, y se intenta crear una nueva región con el puerto en cuestión en su ruta jerárquica, cxl_port_attach_region() no puede encontrar un decodificador de puerto (como sería de esperar), y cae en la ruta de error/limpieza. Sin embargo, durante la limpieza de la referencia de la región, una comprobación de cordura intenta desreferenciar el decodificador, que en el caso anterior no existía. Esto causa un ERROR de desreferencia de puntero NULL. Para corregir esto, refactorice la asignación y desasignación del decodificador en rutinas de ayuda, y en esta rutina 'libre', verifique que el decodificador, @cxld, sea válido antes de intentar cualquier operación en él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/region: Corregir la validación del ordenamiento HPA de la región. Algunas regiones pueden no tener ningún espacio de direcciones asignado. Omítalos al validar el orden de HPA; de lo contrario, puede producirse un fallo como el siguiente: devm_cxl_add_region: cxl_acpi cxl_acpi.0: decoder3.4: created region9 BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 [..] RIP: 0010:store_targetN+0x655/0x1740 [cxl_core] [..] Seguimiento de llamadas: kernfs_fop_write_iter+0x144/0x200 vfs_write+0x24a/0x4d0 ksys_write+0x69/0xf0 do_syscall_64+0x3a/0x90 store_targetN+0x655/0x1740: alloc_region_ref at drivers/cxl/core/region.c:676 (integrado por) cxl_port_attach_region en drivers/cxl/core/region.c:850 (integrado por) cxl_region_attach en drivers/cxl/core/region.c:1290 (integrado por) attached_target en drivers/cxl/core/region.c:1410 (integrado por) store_targetN en drivers/cxl/core/region.c:1453

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Arreglo de use-after-free para ftrace_ops dinámicos KASAN informó de un use-after-free con operaciones ftrace [1]. Se encontró desde vmcore que perf había registrado dos operaciones con el mismo contenido sucesivamente, ambas dinámicas. Después de anular el registro de la segunda operación, se produjo un use-after-free. En ftrace_shutdown(), cuando se anula el registro de la segunda operación, el comando FTRACE_UPDATE_CALLS no se establece porque hay otra operación habilitada con el mismo contenido. Además, ambas operaciones son dinámicas y la función de devolución de llamada de ftrace es ftrace_ops_list_func, por lo que el comando FTRACE_UPDATE_TRACE_FUNC no se establecerá. Finalmente, el valor de 'command' será 0 y ftrace_shutdown() omitirá la sincronización de rcu. Sin embargo, ftrace puede estar activado. Cuando se libera la operación, otra CPU puede estar accediendo a ella. Agregue la sincronización faltante para solucionar este problema. [1] ERROR: KASAN: use-after-free en __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [en línea] ERROR: KASAN: use-after-free en ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Lectura de tamaño 8 en la dirección ffff56551965bbc8 por la tarea syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 No contaminado 5.10.0 #7 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [en línea] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [en línea] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [en línea] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [en línea] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [en línea] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Asignado por la tarea 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [en línea] __kasan_kmalloc mm/kasan/common.c:479 [en línea] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [en línea] kzalloc include/linux/slab.h:675 [en línea] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [en línea] __do_sys_perf_event_open kernel/events/core.c:11831 [en línea] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Liberado por la tarea 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [en línea] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [en línea] slab_free_freelist_hook mm/slub.c:1608 [en línea] slab_free mm/slub.c:3179 [en línea] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [en línea] __do_sys_perf_event_open kernel/events/core.c:11831 [en línea] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: kprobe: Se corrige la fuga de memoria en test_gen_kprobe/kretprobe_cmd(). test_gen_kprobe_cmd() solo libera búfer en la ruta de fallo, por lo que el búfer se filtrará cuando no haya fallo. Se traslada kfree(buf) de la ruta de fallo a la ruta común para evitar la fuga de memoria. El mismo motivo y solución se aplican en test_gen_kretprobe_cmd(). Objeto sin referencia 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: capacidades: reparar posible fuga de memoria en la ruta de error de vfs_getxattr_alloc() En cap_inode_getsecurity(), utilizaremos vfs_getxattr_alloc() para completar la asignación de memoria de tmpbuf, si hemos completado la asignación de memoria de tmpbuf, pero no pudimos llamar a handler->get(...), habrá una fuga de memoria en la siguiente lógica: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ asignar para tmpbuf */ |-- valor = krealloc(*xattr_value, error + 1, flags) | /* ^^^ asignar memoria */ |-- error = handler->get(handler, ...) | /* ¡error! */ |-- *xattr_value = valor | /* xattr_value es &tmpbuf (¡pérdida de memoria!) */ Intentaremos liberar (tmpbuf) después de que vfs_getxattr_alloc() no pueda solucionarlo. [MP: línea de asunto y ajustes de backtrace]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscrypt: corrección de fuga de memoria del llavero en caso de fallo de montaje. El commit d7e7b9af104c ("fscrypt: dejar de usar el subsistema de llaveros para fscrypt_master_key") trasladó la destrucción del llavero de __put_super() a generic_shutdown_super() para que los dispositivos de bloque del sistema de archivos sigan disponibles. Desafortunadamente, esto provoca una fuga de memoria si se intenta un montaje con la opción test_dummy_encryption, pero el montaje falla después de que la opción ya se haya procesado. Para solucionarlo, intente la destrucción del llavero en ambos lugares.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: Rechazar intentos de consumir o actualizar gfn_to_pfn_cache inactivo. Rechazar kvm_gpc_check() y kvm_gpc_refresh() si la caché está inactiva. No verificar el indicador de activo durante la actualización es particularmente grave, ya que KVM puede terminar con una caché válida inactiva, lo que puede provocar diversos errores de use-after-free, como consumir un puntero de kernel nulo o perder una invalidación de mmu_notifier debido a que la caché no está en la lista de gfns para invalidar. Tenga en cuenta que "active" debe establecerse solo si la caché está en la lista de cachés, es decir, es accesible mediante eventos mmu_notifier. Si se produce un evento mmu_notifier relevante mientras la caché está activa, pero no está en la lista, KVM no adquirirá el bloqueo de la caché y, por lo tanto, no serializará el evento mmu_notifier con usuarios activos ni con kvm_gpc_refresh(). Una competencia entre KVM_XEN_ATTR_TYPE_SHARED_INFO y KVM_XEN_HVM_EVTCHN_SEND puede explotarse para activar el error. 1. Desactivar caché shinfo: kvm_xen_hvm_set_attr caso KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = falso gpc->khva = NULL gpc->active = falso Resultado: activo = falso, válido = falso 2. Causar actualización de caché: kvm_arch_vm_ioctl caso KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check devolver -EWOULDBLOCK porque !gpc->valid kvm_xen_set_evtchn_fast devolver -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = verdadero gpc->khva = no NULL Resultado: activo = falso, válido = verdadero 3. Competencia ioctl KVM_XEN_HVM_EVTCHN_SEND contra ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl caso KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr caso KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ La comprobación pasa porque gpc->valid sigue siendo cierto, aunque gpc->khva ya sea NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits)