GHSA-GPQ6-RRXF-V33X

Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-30 03:37
VLAI
Details

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)) >= memslot->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->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->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-52969"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T17:17:07Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Reject wrapped offset in kvm_reset_dirty_gfn()\n\nkvm_reset_dirty_gfn() guards the gfn range with\n\n\tif (!memslot || (offset + __fls(mask)) \u003e= memslot-\u003enpages)\n\t\treturn;\n\nbut offset is u64 and the addition is unchecked.  The check can be\nsilently bypassed by a u64 wrap.\n\nThe dirty ring backing those entries is MAP_SHARED at\nKVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the\nslot and offset fields of any entry between when the kernel pushes\nthem and when KVM_RESET_DIRTY_RINGS consumes them.  On reset,\nkvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds\nthem straight back into this check; only the flags handshake is\ntreated as the handover, the slot/offset payload is taken on trust.\n\nCrafting two entries\n\n\tentry[i].offset   = 0xffffffffffffffc1\n\tentry[i+1].offset = 0\n\nmakes the coalescing loop in kvm_dirty_ring_reset() compute\n\n\tdelta = (s64)(0 - 0xffffffffffffffc1) = 63\n\nwhich falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the\nexisting mask by setting bit 63.  The trailing kvm_reset_dirty_gfn()\ncall then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63;\nthe sum is 0 in u64 and the bounds check passes.\n\nThat offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked()\nunchanged.  On the legacy MMU path -- kvm_memslots_have_rmaps() ==\ntrue, i.e. shadow paging, any VM that has allocated shadow roots, or\na write-tracked slot -- it reaches gfn_to_rmap(), which indexes\nslot-\u003earch.rmap[0][] with a near-U64_MAX gfn.  That is an\nout-of-bounds load of a kvm_rmap_head, followed by a conditional\nclear of PT_WRITABLE_MASK in whatever the loaded pointer points at.\nThe path is reachable from any process holding /dev/kvm.\n\nRange-check offset on its own first, so the addition cannot wrap.\nmemslot-\u003enpages is bounded well below U64_MAX, so once offset \u003c\nnpages holds, offset + __fls(mask) (with __fls(mask) \u003c BITS_PER_LONG)\nstays in range.",
  "id": "GHSA-gpq6-rrxf-v33x",
  "modified": "2026-06-30T03:37:12Z",
  "published": "2026-06-24T18:32:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52969"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-52969"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492434"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/01b71b930f15728aa8599478a7ce90c19dcd9fc2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d419c23bb11b5c9664de777c47c1f04a235882d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0eb281eb95b2d4eea4db1da5fe91023aecc97095"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/577a8d3bae0531f0e5ccfac919cd8192f920a804"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/74f1a22f7a80f03d28ad8551a2d25d563433addf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b315b033a877b1ee6d827810b5d7bb4392ffcf8d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ecf9b3ea7847fe14f34b8c41f00de1eb95c747da"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52969.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…