CVE-2024-50139

What it actually does

The flaw triggers a shift exponent of 33 on a 32-bit int during clidr register reset in KVM arm64 sys_regs handling when MTE is enabled on the host, causing an out-of-bounds shift during VCPU initialization.

Why it matters to the business

Virtual machines on affected arm64 Linux hosts may fail to start or experience kernel instability when MTE is active, leading to operational disruption for virtualization workloads until kernels are updated.

How an attack unfolds

An attacker with the ability to initialize a KVM VCPU on an MTE-enabled arm64 host triggers the reset path in kvm_reset_sys_regs, causing the oversized shift during clidr handling; no remote unauthenticated path is indicated and threat actor references point to general kernel exploitation patterns rather than this specific issue.

How to fix it

Update the Linux kernel to the commit 04ed2ba07ce73f323052475fbd33d647aca3ff2e or later stable releases that contain the fix for the shift calculation in arch/arm64/kvm/sys_regs.c.

How to confirm the fix worked

Boot the updated kernel, enable MTE, start a VM, and confirm absence of UBSAN shift-out-of-bounds reports during VCPU reset; inspect the sys_regs.c file for the corrected shift logic.

Typical attack path

1. Obtain local or VM-management access to an arm64 Linux host running an affected kernel with MTE enabled
2. Issue a VCPU initialization or target-setting ioctl via QEMU/KVM
3. Trigger kvm_reset_vcpu which calls kvm_reset_sys_regs and reset_clidr
4. Execute the oversized left-shift operation on a 32-bit value

How to detect it

Search kernel logs for UBSAN shift-out-of-bounds messages referencing reset_clidr or sys_regs.c during QEMU/KVM VCPU initialization; review audit logs for repeated failed VM starts on MTE-enabled arm64 systems.

What your security team should do

• Prioritize kernel updates on all arm64 hosts using KVM with MTE
• Monitor for UBSAN reports in kernel logs during VM initialization
• Test VM startup after patching to verify stability