<Vulnerability name="CVE-2026-52969">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Important</ThreatSeverity>
    <PublicDate>2026-06-24T00:00:00</PublicDate>
    <Bugzilla id="2492434" url="https://bugzilla.redhat.com/show_bug.cgi?id=2492434" xml:lang="en:us">
kernel: KVM: Reject wrapped offset in kvm_reset_dirty_gfn()
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>7.0</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-190</CWE>
    <Details xml:lang="en:us" source="Mitre">
In the Linux kernel, the following vulnerability has been resolved:

KVM: Reject wrapped offset in kvm_reset_dirty_gfn()

kvm_reset_dirty_gfn() guards the gfn range with

	if (!memslot || (offset + __fls(mask)) &gt;= memslot-&gt;npages)
		return;

but offset is u64 and the addition is unchecked.  The check can be
silently bypassed by a u64 wrap.

The dirty ring backing those entries is MAP_SHARED at
KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the
slot and offset fields of any entry between when the kernel pushes
them and when KVM_RESET_DIRTY_RINGS consumes them.  On reset,
kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds
them straight back into this check; only the flags handshake is
treated as the handover, the slot/offset payload is taken on trust.

Crafting two entries

	entry[i].offset   = 0xffffffffffffffc1
	entry[i+1].offset = 0

makes the coalescing loop in kvm_dirty_ring_reset() compute

	delta = (s64)(0 - 0xffffffffffffffc1) = 63

which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the
existing mask by setting bit 63.  The trailing kvm_reset_dirty_gfn()
call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63;
the sum is 0 in u64 and the bounds check passes.

That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked()
unchanged.  On the legacy MMU path -- kvm_memslots_have_rmaps() ==
true, i.e. shadow paging, any VM that has allocated shadow roots, or
a write-tracked slot -- it reaches gfn_to_rmap(), which indexes
slot-&gt;arch.rmap[0][] with a near-U64_MAX gfn.  That is an
out-of-bounds load of a kvm_rmap_head, followed by a conditional
clear of PT_WRITABLE_MASK in whatever the loaded pointer points at.
The path is reachable from any process holding /dev/kvm.

Range-check offset on its own first, so the addition cannot wrap.
memslot-&gt;npages is bounded well below U64_MAX, so once offset &lt;
npages holds, offset + __fls(mask) (with __fls(mask) &lt; BITS_PER_LONG)
stays in range.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) component. A local attacker with access to /dev/kvm could exploit an integer overflow vulnerability in the kvm_reset_dirty_gfn() function. By manipulating dirty ring entries, the attacker can bypass a bounds check, leading to an out-of-bounds memory access. This could result in information disclosure or potentially cause a denial of service.
    </Details>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-52969
https://nvd.nist.gov/vuln/detail/CVE-2026-52969
https://lore.kernel.org/linux-cve-announce/2026062439-CVE-2026-52969-8aa9@gregkh/T
    </References>
</Vulnerability>