REDHAT-BUG-2543219: Medium severity Kubevirt virt-controller vulnerability
A flaw was found in KubeVirt's virt-controller. A namespace tenant with permission to create VirtualMachineInstance resources can submit a VMI with an empty ephemeral volume specification (ephemeral: {}). The admission webhook validates that the Ephemeral field is non-nil but does not check the inner PersistentVolumeClaim pointer, which defaults to nil as an optional field. When virt-controller processes this VMI, the rendervolumes code dereferences the nil PersistentVolumeClaim pointer, causing a panic. Because the Kubernetes crash handler re-panics by default and the malformed VMI persists in etcd, the controller enters a permanent crash loop, blocking all VM lifecycle operations cluster-wide until an administrator manually deletes the offending VMI.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the controller crash loop?
A tenant in any namespace who has permission to create VirtualMachineInstance resources can trigger it by submitting a malformed VMI. No broader cluster-administration permission is described as necessary.
What malformed configuration causes the failure?
The VMI must include an empty ephemeral volume specification, expressed as ephemeral: {}. This leaves the optional inner PersistentVolumeClaim pointer nil, which passes admission validation but is later dereferenced by virt-controller.
What is the operational impact once exploitation succeeds?
virt-controller enters a persistent crash loop because the malformed VMI remains stored in etcd and is processed again after restart. This blocks VM lifecycle operations across the cluster.
What can administrators do if the controller is already crash-looping?
Manually delete the offending malformed VMI. Removing it prevents virt-controller from repeatedly processing the nil PersistentVolumeClaim pointer.