cve/2024/CVE-2024-55881.md

### [CVE-2024-55881](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-55881)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=5.16%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=5969e2435cbd7f0ce8c28d717bfc39987ee8d8f1%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=b5aead0064f33ae5e693a364e3204fe1c0ac9af2%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Play nice with protected guests in complete_hypercall_exit()Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bithypercall when completing said hypercall.  For guests with protected state,e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bitmode as the vCPU state needed to detect 64-bit mode is unavailable.Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGEhypercall via VMGEXIT trips the WARN:  ------------[ cut here ]------------  WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm]  Modules linked in: kvm_amd kvm ... [last unloaded: kvm]  CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470  Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024  RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm]  Call Trace:   <TASK>   kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm]   kvm_vcpu_ioctl+0x54f/0x630 [kvm]   __se_sys_ioctl+0x6b/0xc0   do_syscall_64+0x83/0x160   entry_SYSCALL_64_after_hwframe+0x76/0x7e   </TASK>  ---[ end trace 0000000000000000 ]---

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/oogasawa/Utility-security
- https://github.com/w4zu/Debian_security