"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: usar mutex dedicado para proteger kvm_usage_count para evitar un bloqueo Use un mutex dedicado para proteger kvm_usage_count para reparar un posible bloqueo en x86 debido a una cadena de bloqueos y sincronizaciones SRCU. Traduciendo el siguiente splat lockdep, CPU1 #6 esperar\u00e1 a CPU0 #1, CPU0 #8 esperar\u00e1 a CPU2 #3 y CPU2 #7 esperar\u00e1 a CPU1 #4 (si hay un escritor, debido a la imparcialidad de los sem\u00e1foros de lectura/escritura). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Tenga en cuenta que es probable que haya m\u00e1s bloqueos potenciales en KVM x86, por ejemplo, el mismo patr\u00f3n de tomar cpu_hotplug_lock fuera de kvm_lock probablemente exista con __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() Pero, en realidad, activar dichos bloqueos es m\u00e1s que raro debido a la combinaci\u00f3n de dependencias y tiempos involucrados. Por ejemplo, el notificador cpufreq solo se usa en CPU m\u00e1s antiguas sin un TSC constante, es muy poco com\u00fan alterar la mitigaci\u00f3n de p\u00e1ginas enormes de NX mientras las m\u00e1quinas virtuales se est\u00e1n ejecutando, y hacerlo mientras tambi\u00e9n se conecta o desconecta una CPU (necesario para generar contenci\u00f3n en cpu_hotplug_lock) ser\u00eda a\u00fan m\u00e1s inusual. La soluci\u00f3n m\u00e1s s\u00f3lida para el problema general de cpu_hotplug_lock es probablemente cambiar vm_list para que sea una lista protegida por RCU, por ejemplo, para que el notificador cpufreq de x86 no tome kvm_lock. Por ahora, conform\u00e9monos con arreglar el bloqueo m\u00e1s evidente, ya que cambiar a una lista protegida por RCU es un cambio mucho m\u00e1s complejo, pero agregue un comentario en locking.rst para indicar que se debe tener cuidado al recorrer manteniendo kvm_lock y recorrer vm_list. ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.10.0-smp--c257535a0c9d-pip #330 Tainted: GSO ------------------------------------------------------ tee/35048 est\u00e1 intentando adquirir el bloqueo: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, en: set_nx_huge_pages+0x179/0x1e0 [kvm] pero la tarea ya tiene el bloqueo: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, en: set_nx_huge_pages+0x14a/0x1e0 [kvm] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: Bloqueo de lectura de CPU + 0x2e/0xb0 Clave est\u00e1tica lenta Inc + 0x16/0x30 Base de configuraci\u00f3n de lapic Lapic + 0x6a/0x1c0 [kvm] Base de configuraci\u00f3n de apic Lapic + 0x8f/0xe0 [kvm] MSR com\u00fan Lapic + 0x9ae/0xf80 [kvm] MSR vmx + 0xa54/0xbe0 [kvm_intel] MSR + 0xb6/0x1a0 [kvm] VCPUE ioctl + 0xeca/0x10c0 [kvm] VCPUE ioctl + 0x485/0x5b0 [kvm] SYS ioctl + 0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncado---"
