GitHub Security Advisory: GHSA-9m94-w2vq-hcf9
Package: kubevirt.io/kubevirt (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: < 1.7.0-beta.0
Patched in: 1.7.0-beta.0

Summary: KubeVirt VMI Denial-of-Service (DoS) Using Pod Impersonation

Details:
### Summary
_Short summary of the problem. Make the impact and severity as clear as possible.

A logic flaw in the `virt-controller` allows an attacker to disrupt the control over a running VMI by creating a pod with the same labels as the legitimate `virt-launcher` pod associated with the VMI. This can mislead the `virt-controller` into associating the fake pod with the VMI, resulting in incorrect status updates and potentially causing a DoS (Denial-of-Service).


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

A vulnerability has been identified in the logic responsible for reconciling the state of VMI. Specifically, it is possible to associate a malicious attacker-controlled pod with an existing VMI running within the same namespace as the pod, thereby replacing the legitimate `virt-launcher` pod associated with the VMI.

The `virt-launcher` pod is critical for enforcing the isolation mechanisms applied to the QEMU process that runs the virtual machine. It also serves, along with `virt-handler`, as a management interface that allows cluster users, operators, or administrators to control the lifecycle of the VMI (e.g., starting, stopping, or migrating it).

When `virt-controller` receives a notification about a change in a VMI's state, it attempts to identify the corresponding `virt-launcher` pod. This is necessary in several scenarios, including:

- When hardware devices are requested to be hotplugged into the VMI—they must also be hotplugged into the associated `virt-launcher` pod.
- When additional RAM is requested—this may require updating the `virt-launcher` pod's cgroups.
- When additional CPU resources are added—this may also necessitate modifying the `virt-launcher` pod's cgroups.
- When the VMI is scheduled to migrate to another node.

The core issue lies in the implementation of the `GetControllerOf` function, which is responsible for determining the controller (i.e., owning resource) of a given pod. In its current form, this logic can be manipulated, allowing an attacker to substitute a rogue pod in place of the legitimate `virt-launcher`, thereby compromising the VMI's integrity and control mechanisms.

```go
//pkg/controller/controller.go

func CurrentVMIPod(vmi *v1.VirtualMachineInstance, podIndexer cache.Indexer) (*k8sv1.Pod, error) {
	// Get all pods from the VMI namespace which contain the label "kubevirt.io"
	objs, err := podIndexer.ByIndex(cache.NamespaceIndex, vmi.Namespace)
	if err != nil {
		return nil, err
	}
	pods := []*k8sv1.Pod{}
	for _, obj := range objs {
		pod := obj.(*k8sv1.Pod)
		pods = append(pods, pod)
	}

	var curPod *k8sv1.Pod = nil
	for _, pod := range pods {
		if !IsControlledBy(pod, vmi) {
			continue
		}

		if vmi.Status.NodeName != "" &&
			vmi.Status.NodeName != pod.Spec.NodeName {
			// This pod isn't scheduled to the current node.
			// This can occur during the initial migration phases when
			// a new target node is be