Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/kasan: limitar el aumento del tamaño del subproceso KASAN a 32 KB. Se considera que KASAN aumenta el uso de la pila, hasta el punto de que se informó que provoca un desbordamiento de la pila en algunas máquinas de 32 bits ( ver enlace). Para evitar desbordamientos, el tamaño de la pila se duplicó para las compilaciones de KASAN en el commit 3e8635fb2e07 ("powerpc/kasan: Forzar el aumento del tamaño del subproceso con KASAN"). Sin embargo, con un tamaño de pila de 32 KB para empezar, la duplicación conduce a una pila de 64 KB, lo que provoca errores de compilación: arch/powerpc/kernel/switch.S:249: Error: operando fuera de rango (0x000000000000fe50 no está entre 0xffffffffffff8000 y 0x00000000000007fff) Aunque el conjunto podría modificarse, en la práctica una pila de 32 KB parece suficiente incluso para compilaciones KASAN; el uso adicional parece estar en el rango de 2 a 3 KB para una compilación KASAN de 64 bits. Por lo tanto, solo aumente la pila para KASAN si el tamaño de la pila es <32 KB.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: ccp - Corrige la desreferencia del puntero nulo en __sev_platform_shutdown_locked El dispositivo de la plataforma SEV se puede apagar con un psp_master nulo, por ejemplo, usando DEBUG_TEST_DRIVER_REMOVE. Encontrado usando KASAN: [ 137.148210] ccp 0000:23:00.1: dispositivo de habilitación (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no hay colas de comandos disponibles [ 137.170598] ccp 0000:23:00.1: sev habilitado [ 13 7.174645 ] ccp 0000:23:00.1: psp habilitado [137.178890] falla de protección general, probablemente para dirección no canónica 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [137.182693] KASAN: null-ptr-deref en rango [0x00 000000000000f0- 0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 No contaminado 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.1826 93] Código: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 00000000000000000 RC X: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R0 8 : 0000000000000000 R09: ffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881 e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:00000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693 ] Seguimiento de llamadas: [ 137.182693] [ 137.182693] ? show_regs+0x6c/0x80 [137.182693]? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [137.182693]? asm_exc_general_protection+0x2b/0x30 [137.182693]? __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0 xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693]realmente_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.18 2693] ? __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10 [137.182693]? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [137.182693]? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_ registro_controlador+0x1d6/0x2a0 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693]? esrt_sysfs_init+0x1cd/0x5d0 [137.182693]? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [137.182693]? parameq+0x80/0xf0 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693]? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [137.182693]? kasan_populate_vmalloc_pte+0x171/0x190 [137.182693]? srso_return_thunk+0x5/0x5f [137.182693] kernel_init_freeable+0xa64/0x1050 [137.182693]? __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: corrige el error de doble liberación El almacenamiento de los datos de registro de PC TLV no se realizó como el resto del almacenamiento en el área drv->fw, que se borra en el fin de la desasignación. Por lo tanto, la liberación también debe realizarse de manera diferente, anulándolo explícitamente después de la liberación, ya que de lo contrario hay un desagradable error de doble liberación aquí si un archivo no se carga después de haber sido analizado y obtenemos otra liberación más tarde (por ejemplo porque no existe ningún otro archivo). Solucione el problema agregando la asignación NULL que falta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs,hugetlb: corrige la desreferencia del puntero NULL en hugetlbs_fill_super Al configurar un SYSTEM de archivos de Hugetlb a través de la llamada al SYSTEM fsconfig(), existe una posible desreferencia de NULL en hugetlbfs_fill_super() causada por la asignación de NULL a ctx. ->hstate en hugetlbfs_parse_param() cuando el tamaño de página solicitado no es válido. Por ejemplo: siguiendo los siguientes pasos: fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, "tamaño de página", "1024", 0); fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); Dado que el "tamaño de página" solicitado no es válido, ctxt->hstate será reemplazado por NULL, perdiendo su valor anterior, e imprimiremos un error: ... ... case Opt_pagesize: ps = memparse(param->string, &descansar); ctx->hestado = h; if (!ctx->hstate) { pr_err("Tamaño de página no admitido %lu MB\n", ps / SZ_1M); devolver -EINVAL; } devolver 0; ... ... Esto es un problema porque más adelante eliminaremos la referencia a ctxt->hstate en hugetlbfs_fill_super() ... ... sb->s_blocksize = huge_page_size(ctx->hstate); ... ... Causando debajo Ups. Solucione este problema reemplazando el valor cxt->hstate solo cuando se sepa que el tamaño de página es válido. kernel: hugetlbfs: Tamaño de página no admitido 0 MB kernel: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000028 kernel: #PF: acceso de lectura del supervisor en modo kernel kernel: #PF: código_error(0x0000) - página no presente kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Ups: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Contaminado: GE 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344 Kernel aabc35190ae8f: Nombre del hardware: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 03/05/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Código: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff R DI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: fffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7 000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Seguimiento de llamadas: kernel: kernel: ? __die_body+0x1a/0x60 núcleo: ? page_fault_oops+0x16f/0x4a0 núcleo:? search_bpf_extables+0x65/0x70 núcleo:? fixup_exception+0x22/0x310 kernel:? exc_page_fault+0x69/0x150 núcleo:? asm_exc_page_fault+0x22/0x30 núcleo:? __pfx_hugetlbfs_fill_super+0x10/0x10 núcleo:? núcleo enormetlbfs_fill_super+0xb4/0x1a0:? enormetlbfs_fill_super+0x28/0x1a0 kernel:? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: vfs_get_super+0x40/0xa0 kernel:? __pfx_bpf_lsm_capable+0x10/0x10 kernel: vfs_get_tree+0x25/0xd0 kernel: vfs_cmd_create+0x64/0xe0 kernel: __x64_sys_fsconfig+0x395/0x410 kernel: do_syscall_64+0x80/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel:? do_syscall_64+0x8d/0x160 núcleo:? syscall_exit_to_user_mode+0x82/0x240 kernel:? do_syscall_64+0x8d/0x160 núcleo:? exc_page_fault+0x69/0x150 kernel: Entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Código: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: evita el use-after-free en encode_cap_msg() En fs/ceph/caps.c, en encode_cap_msg(), KASAN detectó el error "use after free" en este línea - 'ceph_buffer_get(arg->xattr_buf);'. Esto implica que antes de que el recuento pudiera incrementarse aquí, fue liberado. En el mismo archivo, en "handle_cap_grant()", el refcount se reduce en esta línea: 'ceph_buffer_put(ci->i_xattrs.blob);'. Parece que se produjo una ejecución y la última línea liberó el recurso antes de que la primera línea pudiera incrementarlo. __send_cap() llama a encode_cap_msg() y ceph_check_caps() llama a __send_cap() después de llamar a __prep_cap(). __prep_cap() es donde arg->xattr_buf se asigna a ci->i_xattrs.blob. Este es el punto donde se debe aumentar el recuento para evitar el error "use after free".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hv_netvsc: corrige la condición de ejecución entre netvsc_probe y netvsc_remove En el commit ac5047671758 ("hv_netvsc: deshabilite NAPI antes de cerrar el canal VMBus"), se llamaba a napi_disable para todos los canales, incluidos todos los subcanales sin confirmando si están habilitados o no. Esto provocó que hv_netvsc se colgara en napi_disable, cuando netvsc_probe() terminó de ejecutarse pero nvdev->subchan_work aún no se inició. netvsc_subchan_work() -> rndis_set_subchannel() no ha creado los subcanales y por eso netvsc_sc_open() no se está ejecutando. netvsc_remove() llama a cancel_work_sync(&nvdev->subchan_work), para lo cual netvsc_subchan_work no se ejecutó. netif_napi_add() establece el bit NAPI_STATE_SCHED porque garantiza que NAPI no se pueda programar. Luego netvsc_sc_open() -> napi_enable borrará el bit NAPIF_STATE_SCHED, para que pueda programarse. napi_disable() hace lo contrario. Ahora, durante netvsc_device_remove(), cuando se llama a napi_disable para esos subcanales, napi_disable se atasca en msleep infinito. Esta solución soluciona este problema garantizando que no se llame a napi_disable() para una estructura NAPI no habilitada. Pero netif_napi_del() sigue siendo necesario para estas estructuras NAPI no habilitadas con fines de limpieza. Rastreo de llamadas: [654.559417] tarea:modprobe estado:D pila: 0 pid: 2321 ppid: 1091 banderas:0x00004002 [654.568030] Rastreo de llamadas: [654.571221] [654.573790] __schedule+0x2d6/0x960 [ 65 4.577733] horario+0x69 /0xf0 [654.581214] Schedule_timeout+0x87/0x140 [654.585463]? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 6 54.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [654.611101]? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige un bloqueo en nilfs_lookup_dirty_data_buffers() Syzbot informó un problema de bloqueo en migrar_pages_batch() llamado por mbind() y nilfs_lookup_dirty_data_buffers() llamado en el escritor de registros de nilfs2. Mientras migrar_pages_batch() bloquea una publicación y espera a que se complete la reescritura, el subproceso del escritor de registros que debería completar la reescritura recoge la publicación que se está reescribiendo en nilfs_lookup_dirty_data_buffers() que solicita la creación de registros posteriores y estaba intentando bloquear la fol. Provocando así un punto muerto. En primer lugar, es inesperado que los folios/páginas en medio de la reescritura se actualicen y se ensucien. Nilfs2 agrega una suma de verificación para verificar la validez del registro que se está escribiendo y la usa para la recuperación en el montaje, de modo que se suprimen los cambios de datos durante la reescritura. Dado que esto no funciona, un cierre incorrecto podría provocar que falle la recuperación. La investigación reveló que la causa principal es que la espera para que se complete la reescritura en nilfs_page_mkwrite() es condicional, y si el dispositivo de respaldo no requiere escrituras estables, los datos se pueden modificar sin esperar. Solucione estos problemas haciendo que nilfs_page_mkwrite() espere a que finalice la reescritura independientemente del requisito de escritura estable del dispositivo de respaldo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige la corrupción de datos en la recuperación de bloques dsync para tamaños de bloques pequeños La función auxiliar nilfs_recovery_copy_block() de nilfs_recovery_dsync_blocks(), que recupera datos de los registros creados por escrituras de sincronización de datos durante un montaje después un apagado incorrecto calcula incorrectamente el desplazamiento en la página al copiar los datos de reparación en la memoria caché de la página del archivo. En entornos donde el tamaño del bloque es menor que el tamaño de la página, esta falla puede causar corrupción de datos y pérdida de bytes de memoria no inicializados durante el proceso de recuperación. Solucione estos problemas corrigiendo este cálculo de desplazamiento de bytes en la página.

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: wifi: iwlwifi: mvm: soluciona un fallo cuando nos quedamos sin estaciones Una herramienta DoS que inyecta un montón de marcos de autenticación hacía que nuestro AP fallara. La función iwl_mvm_is_dup() no pudo encontrar los datos dup_data por cola que no estaban asignados. La causa principal de esto es que nos quedamos sin estaciones en el firmware y realmente no agregamos la estación al firmware, pero no devolvimos un error a mac80211. Mac80211 estaba pensando que teníamos la estación y debido a eso, sta_info::uploaded se configuró en 1. Esto permitió que ieee80211_find_sta_by_ifaddr() devolviera un objeto de estación válido, pero que ieee80211_sta no tenía ningún objeto iwl_mvm_sta inicializado y eso causó el bloqueo. Mencioné anteriormente cuando obtuvimos Rx en esa estación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb: se corrigió la regresión en las escrituras cuando se negoció un tamaño de escritura máximo no estándar. La conversión a netfs en el kernel 6.3 provocó una regresión cuando el servidor estableció el tamaño de escritura máximo en un valor inesperado. que no es un múltiplo de 4096 (de manera similar, si el usuario anula el tamaño máximo de escritura configurando el parámetro de montaje "wsize", pero lo establece en un valor que no es un múltiplo de 4096). Cuando el tamaño de escritura negociado no es un múltiplo de 4096, el código netfs puede omitir el final de la página final al realizar escrituras secuenciales grandes, lo que provoca corrupción de datos. Esta sección de código se está reescribiendo/eliminando debido a un gran cambio en netfs, pero hasta ese momento (es decir, para el kernel 6.3 hasta ahora) no podemos admitir tamaños máximos de escritura no estándar. Agregue una advertencia si un usuario especifica un wsize en el montaje que no es un múltiplo de 4096 (y redondea hacia abajo), también agregue un cambio donde redondeamos hacia abajo el tamaño máximo de escritura si el servidor negocia un valor que no es un múltiplo de 4096 ( también tenemos que comprobar que no lo redondeamos a cero).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xen/events: cierre evtchn después de la limpieza del mapeo. Shutdown_pirq y startup_pirq no están tomando irq_mapping_update_lock porque no pueden hacerlo debido a la inversión de bloqueo. Ambos se llaman con el irq_desc->lock en curso. Sin embargo, el orden de bloqueo es primero irq_mapping_update_lock y luego irq_desc->lock. Esto abre múltiples ejecucións: - Shutdown_pirq puede ser interrumpido por una función que asigna un canal de evento: CPU0 CPU1 Shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> devuelve el evtchn e set_evtchn_to_irq(e, irq) recién liberado} xen_irq_info_cleanup() { set_evtchn_to_irq( e, -1) } } Supongamos que aquí el canal de eventos e se refiere aquí al mismo número de canal de eventos. Después de esta ejecución, el mapeo evtchn_to_irq para e no es válido (-1). - __startup_pirq compite con __unbind_from_irq de manera similar. Debido a que __startup_pirq no toma irq_mapping_update_lock, puede tomar el evtchn que __unbind_from_irq está liberando y limpiando actualmente. En este caso, aunque el canal de eventos esté asignado, su asignación se puede desarmar en evtchn_to_irq. La solución es limpiar primero las asignaciones y luego cerrar el canal de eventos. De esta manera, cuando se asigna un canal de eventos, se garantiza que sus posibles asignaciones anteriores de evtchn_to_irq ya no estarán configuradas. Este es también el orden inverso de la asignación donde primero se asigna el canal de evento y luego se configuran las asignaciones. En un kernel 5.10 antes de commit 3fcdaf3d7634 ("xen/events: modificar interfaces internas [un]bind"), encontramos un ERROR como el siguiente durante el sondeo de dispositivos NVMe. El problema es que durante nvme_setup_io_queues, se llama a pci_free_irq para cada dispositivo, lo que resulta en una llamada a Shutdown_pirq. Por lo tanto, con muchos dispositivos nvme es probable que alcance esta ejecución durante el arranque porque habrá múltiples llamadas a Shutdown_pirq y startup_pirq que se ejecutan potencialmente en paralelo. ------------[ cortar aquí ]------------ blkfront: xvda: barrera o descarga: deshabilitado; subvenciones persistentes: habilitadas; descriptores indirectos: habilitado; búfer de rebote: ¡ERROR del kernel habilitado en drivers/xen/events/events_base.c:499! código de operación no válido: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 No contaminado 5.10.201-191.748.amzn2.x86_64 #1 Nombre de hardware: Xen HVM domU, BIOS 4.11.amazon 24/08 /2006 Cola de trabajo: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Código: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 00000000000 00000 R09: ffffffff82d72b00 R10: 00000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 00000000000000000 R14: 00000000ffffffff R15 : 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000000 CR3: 0000000002610001 CR4: 000000000017 06e0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? show_trace_log_lvl+0x1c1/0x2d9? show_trace_log_lvl+0x1c1/0x2d9? set_affinity_irq+0xdc/0x1c0? __die_body.cold+0x8/0xd ? morir+0x2b/0x50 ? do_trap+0x90/0x110? bind_evtchn_to_cpu+0xdf/0xf0? do_error_trap+0x65/0x80? bind_evtchn_to_cpu+0xdf/0xf0? exc_invalid_op+0x4e/0x70? bind_evtchn_to_cpu+0xdf/0xf0? asm_exc_invalid_op+0x12/0x20? bind_evtchn_to_cpu+0xdf/0x ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige la dependencia de bloqueo circular La regla dentro de kvm exige que vcpu->mutex se tome *dentro* de kvm->lock. La regla es violada por pkvm_create_hyp_vm() que adquiere el bloqueo kvm->mientras ya mantiene el bloqueo vcpu->mutex de kvm_vcpu_ioctl(). Evite por completo la dependencia del bloqueo circular protegiendo el identificador hyp vm con config_lock, de forma muy similar a como lo hacemos con otras formas de datos con alcance de VM.