CVE-2024-35804: KVM: x86: Mark target gfn of emulated atomic instruction as dirty
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Mark target gfn of emulated atomic instruction as dirty
When emulating an atomic access on behalf of the guest, mark the target
gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This
fixes a bug where KVM effectively corrupts guest memory during live
migration by writing to guest memory without informing userspace that the
page is dirty.
Marking the page dirty got unintentionally dropped when KVM's emulated
CMPXCHG was converted to do a user access. Before that, KVM explicitly
mapped the guest page into kernel memory, and marked the page dirty during
the unmap phase.
Mark the page dirty even if the CMPXCHG fails, as the old data is written
back on failure, i.e. the page is still written. The value written is
guaranteed to be the same because the operation is atomic, but KVM's ABI
is that all writes are dirty logged regardless of the value written. And
more importantly, that's what KVM did before the buggy commit.
Huge kudos to the folks on the Cc list (and many others), who did all the
actual work of triaging and debugging.
base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64
Security readout for executives and security teams
Plain-English summary
A Linux KVM bookkeeping failure can corrupt a virtual machine's memory during live migration. While emulating an atomic guest operation, KVM may change a guest page without telling migration software. The migration can consequently transfer stale page contents, threatening workload integrity and availability.
Executive priority
Treat this as high priority for virtualization clusters that live-migrate KVM guests because silent guest-memory corruption can affect critical workloads. Expedite remediation before substantial migration activity. Systems without x86 KVM live migration have lower demonstrated urgency. The absence of known active exploitation reduces emergency pressure but does not reduce the operational risk.
Technical view
On affected x86 KVM hosts, emulated CMPXCHG can write the target guest frame without marking it dirty when access does not fault. Even a failed CMPXCHG writes back the old value, and KVM's ABI requires every write to be logged. During live migration, userspace may transfer stale page state. Referenced stable commits restore dirty marking.
Likely exposure
Exposure is concentrated on affected Linux x86 hosts running KVM and performing live migration. The relevant condition involves guest atomic instructions that KVM must emulate. Ordinary Linux systems without KVM workloads, and KVM environments that never live-migrate guests, are not shown by the supplied evidence to experience this migration-corruption path.
Exploitation context
CISA KEV status is false, and the bundle provides no evidence of active exploitation or a public exploit. CVSS characterizes potential abuse as local, low-complexity, low-privilege, and requiring no user interaction. The cited description establishes a memory-corruption condition during migration, not a demonstrated attack chain.
Researcher notes
The regression occurred when emulated CMPXCHG changed to userspace access and lost dirty marking previously performed during unmapping. Dirty logging remains required even when comparison fails because the old value is written back. The supplied version list includes unusual entries and commit identifiers, so downstream vendor backport confirmation is necessary before declaring a build affected or fixed.
Mitigation direction
Identify x86 Linux hosts running KVM and prioritize those performing live migration.
Apply a distribution-supported kernel containing the referenced KVM dirty-logging fix.
Confirm exact fixed builds with the Linux vendor; supplied affected-version metadata is irregular.
Follow vendor guidance for activating the corrected kernel and completing required host maintenance.
Validation and detection
Inventory running host kernels, x86 KVM usage, and live-migration capability.
Map each deployed build to vendor backport status or the referenced stable commits.
Verify the corrected kernel is running after maintenance, not merely installed.
Validate controlled live migration and dirty-page tracking in a staging environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35804 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.