GSD-2021-47092
Vulnerability from gsd - Updated: 2024-03-01 06:04Details
In the Linux kernel, the following vulnerability has been resolved:
KVM: VMX: Always clear vmx->fail on emulation_required
Revert a relatively recent change that set vmx->fail if the vCPU is in L2
and emulation_required is true, as that behavior is completely bogus.
Setting vmx->fail 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->fail has no immediate effect,
i.e. KVM calls into handle_invalid_guest_state() and vmx->fail is ignored.
Setting vmx->fail can ultimately result in a WARN in nested_vmx_vmexit()
firing when tearing down the VM as KVM never expects vmx->fail 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: <0f> 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
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2021-47092"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Always clear vmx-\u003efail on emulation_required\n\nRevert a relatively recent change that set vmx-\u003efail if the vCPU is in L2\nand emulation_required is true, as that behavior is completely bogus.\nSetting vmx-\u003efail and synthesizing a VM-Exit is contradictory and wrong:\n\n (a) it\u0027s impossible to have both a VM-Fail and VM-Exit\n (b) vmcs.EXIT_REASON is not modified on VM-Fail\n (c) emulation_required refers to guest state and guest state checks are\n always VM-Exits, not VM-Fails.\n\nFor KVM specifically, emulation_required is handled before nested exits\nin __vmx_handle_exit(), thus setting vmx-\u003efail has no immediate effect,\ni.e. KVM calls into handle_invalid_guest_state() and vmx-\u003efail is ignored.\nSetting vmx-\u003efail can ultimately result in a WARN in nested_vmx_vmexit()\nfiring when tearing down the VM as KVM never expects vmx-\u003efail to be set\nwhen L2 is active, KVM always reflects those errors into L1.\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548\n nested_vmx_vmexit+0x16bd/0x17e0\n arch/x86/kvm/vmx/nested.c:4547\n Modules linked in:\n CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547\n Code: \u003c0f\u003e 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80\n Call Trace:\n vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [inline]\n nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330\n vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799\n kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989\n kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:441\n kvm_free_vcpus arch/x86/kvm/x86.c:11426 [inline]\n kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545\n kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1189 [inline]\n kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1220\n kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3489\n __fput+0x3fc/0x870 fs/file_table.c:280\n task_work_run+0x146/0x1c0 kernel/task_work.c:164\n exit_task_work include/linux/task_work.h:32 [inline]\n do_exit+0x705/0x24f0 kernel/exit.c:832\n do_group_exit+0x168/0x2d0 kernel/exit.c:929\n get_signal+0x1740/0x2120 kernel/signal.c:2852\n arch_do_signal_or_restart+0x9c/0x730 arch/x86/kernel/signal.c:868\n handle_signal_work kernel/entry/common.c:148 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:172 [inline]\n exit_to_user_mode_prepare+0x191/0x220 kernel/entry/common.c:207\n __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]\n syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300\n do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x44/0xae",
"id": "GSD-2021-47092",
"modified": "2024-03-01T06:04:48.299103Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2021-47092",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "c8607e4a086f",
"version_value": "e4e4e7cb2298"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"status": "affected",
"version": "5.15"
},
{
"lessThan": "5.15",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.12",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Always clear vmx-\u003efail on emulation_required\n\nRevert a relatively recent change that set vmx-\u003efail if the vCPU is in L2\nand emulation_required is true, as that behavior is completely bogus.\nSetting vmx-\u003efail and synthesizing a VM-Exit is contradictory and wrong:\n\n (a) it\u0027s impossible to have both a VM-Fail and VM-Exit\n (b) vmcs.EXIT_REASON is not modified on VM-Fail\n (c) emulation_required refers to guest state and guest state checks are\n always VM-Exits, not VM-Fails.\n\nFor KVM specifically, emulation_required is handled before nested exits\nin __vmx_handle_exit(), thus setting vmx-\u003efail has no immediate effect,\ni.e. KVM calls into handle_invalid_guest_state() and vmx-\u003efail is ignored.\nSetting vmx-\u003efail can ultimately result in a WARN in nested_vmx_vmexit()\nfiring when tearing down the VM as KVM never expects vmx-\u003efail to be set\nwhen L2 is active, KVM always reflects those errors into L1.\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548\n nested_vmx_vmexit+0x16bd/0x17e0\n arch/x86/kvm/vmx/nested.c:4547\n Modules linked in:\n CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547\n Code: \u003c0f\u003e 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80\n Call Trace:\n vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [inline]\n nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330\n vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799\n kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989\n kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:441\n kvm_free_vcpus arch/x86/kvm/x86.c:11426 [inline]\n kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545\n kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1189 [inline]\n kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1220\n kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3489\n __fput+0x3fc/0x870 fs/file_table.c:280\n task_work_run+0x146/0x1c0 kernel/task_work.c:164\n exit_task_work include/linux/task_work.h:32 [inline]\n do_exit+0x705/0x24f0 kernel/exit.c:832\n do_group_exit+0x168/0x2d0 kernel/exit.c:929\n get_signal+0x1740/0x2120 kernel/signal.c:2852\n arch_do_signal_or_restart+0x9c/0x730 arch/x86/kernel/signal.c:868\n handle_signal_work kernel/entry/common.c:148 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:172 [inline]\n exit_to_user_mode_prepare+0x191/0x220 kernel/entry/common.c:207\n __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]\n syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300\n do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x44/0xae"
}
]
},
"generator": {
"engine": "bippy-4986f5686161"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/e4e4e7cb229821cd215031abc47efdab5486a67c",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/e4e4e7cb229821cd215031abc47efdab5486a67c"
},
{
"name": "https://git.kernel.org/stable/c/a80dfc025924024d2c61a4c1b8ef62b2fce76a04",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/a80dfc025924024d2c61a4c1b8ef62b2fce76a04"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Always clear vmx-\u003efail on emulation_required\n\nRevert a relatively recent change that set vmx-\u003efail if the vCPU is in L2\nand emulation_required is true, as that behavior is completely bogus.\nSetting vmx-\u003efail and synthesizing a VM-Exit is contradictory and wrong:\n\n (a) it\u0027s impossible to have both a VM-Fail and VM-Exit\n (b) vmcs.EXIT_REASON is not modified on VM-Fail\n (c) emulation_required refers to guest state and guest state checks are\n always VM-Exits, not VM-Fails.\n\nFor KVM specifically, emulation_required is handled before nested exits\nin __vmx_handle_exit(), thus setting vmx-\u003efail has no immediate effect,\ni.e. KVM calls into handle_invalid_guest_state() and vmx-\u003efail is ignored.\nSetting vmx-\u003efail can ultimately result in a WARN in nested_vmx_vmexit()\nfiring when tearing down the VM as KVM never expects vmx-\u003efail to be set\nwhen L2 is active, KVM always reflects those errors into L1.\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548\n nested_vmx_vmexit+0x16bd/0x17e0\n arch/x86/kvm/vmx/nested.c:4547\n Modules linked in:\n CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547\n Code: \u003c0f\u003e 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80\n Call Trace:\n vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [inline]\n nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330\n vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799\n kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989\n kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:441\n kvm_free_vcpus arch/x86/kvm/x86.c:11426 [inline]\n kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545\n kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1189 [inline]\n kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1220\n kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3489\n __fput+0x3fc/0x870 fs/file_table.c:280\n task_work_run+0x146/0x1c0 kernel/task_work.c:164\n exit_task_work include/linux/task_work.h:32 [inline]\n do_exit+0x705/0x24f0 kernel/exit.c:832\n do_group_exit+0x168/0x2d0 kernel/exit.c:929\n get_signal+0x1740/0x2120 kernel/signal.c:2852\n arch_do_signal_or_restart+0x9c/0x730 arch/x86/kernel/signal.c:868\n handle_signal_work kernel/entry/common.c:148 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:172 [inline]\n exit_to_user_mode_prepare+0x191/0x220 kernel/entry/common.c:207\n __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]\n syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300\n do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x44/0xae"
}
],
"id": "CVE-2021-47092",
"lastModified": "2024-03-05T13:41:01.900",
"metrics": {},
"published": "2024-03-04T18:15:07.723",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a80dfc025924024d2c61a4c1b8ef62b2fce76a04"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e4e4e7cb229821cd215031abc47efdab5486a67c"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…