{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.15.15-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.15.15-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.15.15-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  KVM: VMX: Always clear vmx-\u003efail on emulation_required  Revert a relatively recent change that set vmx-\u003efail if the vCPU is in L2 and emulation_required is true, as that behavior is completely bogus. Setting vmx-\u003efail and synthesizing a VM-Exit is contradictory and wrong:    (a) it's impossible to have both a VM-Fail and VM-Exit   (b) vmcs.EXIT_REASON is not modified on VM-Fail   (c) emulation_required refers to guest state and guest state checks are       always VM-Exits, not VM-Fails.  For KVM specifically, emulation_required is handled before nested exits in __vmx_handle_exit(), thus setting vmx-\u003efail has no immediate effect, i.e. KVM calls into handle_invalid_guest_state() and vmx-\u003efail is ignored. Setting vmx-\u003efail can ultimately result in a WARN in nested_vmx_vmexit() firing when tearing down the VM as KVM never expects vmx-\u003efail to be set when L2 is active, KVM always reflects those errors into L1.    ------------[ cut here ]------------   WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548                                 nested_vmx_vmexit+0x16bd/0x17e0                                 arch/x86/kvm/vmx/nested.c:4547   Modules linked in:   CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011   RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547   Code: \u003c0f\u003e 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80   Call Trace:    vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [inline]    nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330    vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799    kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989    kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:441    kvm_free_vcpus arch/x86/kvm/x86.c:11426 [inline]    kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545    kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1189 [inline]    kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1220    kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3489    __fput+0x3fc/0x870 fs/file_table.c:280    task_work_run+0x146/0x1c0 kernel/task_work.c:164    exit_task_work include/linux/task_work.h:32 [inline]    do_exit+0x705/0x24f0 kernel/exit.c:832    do_group_exit+0x168/0x2d0 kernel/exit.c:929    get_signal+0x1740/0x2120 kernel/signal.c:2852    arch_do_signal_or_restart+0x9c/0x730 arch/x86/kernel/signal.c:868    handle_signal_work kernel/entry/common.c:148 [inline]    exit_to_user_mode_loop kernel/entry/common.c:172 [inline]    exit_to_user_mode_prepare+0x191/0x220 kernel/entry/common.c:207    __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]    syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300    do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86    entry_SYSCALL_64_after_hwframe+0x44/0xae",
  "id": "DEBIAN-CVE-2021-47092",
  "modified": "2026-09-01T19:48:20.204252212Z",
  "published": "2024-03-04T18:15:07.723Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2021-47092"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2021-47092"
  ]
}