CVE-2014-3690

What it actually does

The KVM subsystem fails to preserve the CR4 control register value across VM entry on Intel processors, allowing a local user with /dev/kvm access to alter TSC behavior via PR_SET_TSC prctl calls in a modified QEMU instance and thereby terminate arbitrary processes or trigger system-wide disruption.

Why it matters to the business

Local attackers can cause denial of service that interrupts workloads running on affected Linux hosts; the presence of five downstream dependents increases the scope of potential availability loss across virtualized environments.

How an attack unfolds

An attacker with local host privileges opens /dev/kvm, launches a modified QEMU instance that issues PR_SET_TSC prctl calls, and leverages the uncleared CR4 state after VM entry to kill target processes or destabilize the host; named threat actors associated with Linux kernel issues have been observed exploring similar vectors.

How to fix it

Upgrade affected packages to the listed fixed versions: horizon on Ubuntu 14.04 LTS to 1:2014.1.5-0ubuntu1, and horizon on Debian 11/12/13 to 2015.1.0+2015.06.09.git15.e63af6c598-1; apply corresponding kernel updates that ensure CR4 preservation after VM entry.

How to confirm the fix worked

Confirm the running kernel is at or beyond 3.17.2, verify that CR4 contents remain unchanged across VM entry in test workloads, and check package versions against the supplied fixed releases for each distribution.

Typical attack path

1. Obtain local access to a host with /dev/kvm permissions
2. Deploy or execute a modified QEMU binary
3. Issue PR_SET_TSC prctl calls inside the guest context
4. Trigger VM exit/entry sequences that leave CR4 inconsistent
5. Cause targeted process termination or host disruption

How to detect it

Review authentication and process-creation logs around /dev/kvm usage, inspect for modified QEMU binaries or unusual prctl invocations, and correlate with process termination events on hosts that allow KVM access; threat-actor references to Linux kernel issues can guide retrospective searches in historic logs.

What your security team should do

• Prioritize patching hosts that expose /dev/kvm to untrusted local users
• Audit user permissions on /dev/kvm and restrict access where possible
• Monitor EPSS and exploit maturity indicators for any future rise despite current low scores
• Test the fixed package versions in staging before broad deployment given the 4350-day publication age