CVE-2021-47049

What it actually does

A use-after-free occurs in the vmbus driver when open_info is added to vmbus_connection.chn_msg_list but error handling in __vmbus_open() frees the structure without removing it from the list, leaving a dangling reference that can be accessed later.

Why it matters to the business

Kernel instability, crashes, or potential code execution in virtualized Linux guests on Hyper-V can disrupt cloud workloads, increase downtime, and raise the risk of compromise in environments relying on Microsoft virtualization.

How an attack unfolds

An attacker with local access triggers an error path during vmbus channel opening so that open_info is freed while still linked in the message list; subsequent list traversal then dereferences the freed memory for exploitation.

How to fix it

Apply the upstream Linux kernel patch that removes open_info from the list before freeing it; rebuild and deploy updated kernels to all affected Hyper-V guests.

How to confirm the fix worked

Confirm the kernel source contains the fix that deletes the entry from chn_msg_list prior to kfree; test vmbus channel open and error paths under stress to ensure no UAF warnings appear.

Typical attack path

1. Obtain local access on a Hyper-V Linux guest
2. Trigger error condition in __vmbus_open()
3. Cause premature free of open_info without list removal
4. Reuse dangling pointer via chn_msg_list access
5. Achieve use-after-free for DoS or privilege escalation

How to detect it

Search kernel logs and dmesg for vmbus or chn_msg_list errors, use-after-free warnings, or panics involving __vmbus_open; monitor guest-to-host channel activity for anomalies.

What your security team should do

• Patch Linux kernels on all Hyper-V virtual machines as soon as fixed builds are available
• Review hypervisor logs for vmbus-related crashes or warnings
• Limit untrusted local access on guest systems until updates are applied