GHSA-H3H3-JQ7C-XGPC
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2025-09-17 18:31In the Linux kernel, the following vulnerability has been resolved:
drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".
Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks.
Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte().
This patch (of 3):
We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage.
(1) We're not checking PTE write permissions.
Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now.
(2) We're not rejecting refcounted pages.
As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them.
(3) We are only looking at the first PTE of a bigger range.
We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing.
{
"affected": [],
"aliases": [
"CVE-2024-38610"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()\n\nPatch series \"mm: follow_pte() improvements and acrn follow_pte() fixes\".\n\nPatch #1 fixes a bunch of issues I spotted in the acrn driver. It\ncompiles, that\u0027s all I know. I\u0027ll appreciate some review and testing from\nacrn folks.\n\nPatch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding\nmore sanity checks, and improving the documentation. Gave it a quick test\non x86-64 using VM_PAT that ends up using follow_pte().\n\n\nThis patch (of 3):\n\nWe currently miss handling various cases, resulting in a dangerous\nfollow_pte() (previously follow_pfn()) usage.\n\n(1) We\u0027re not checking PTE write permissions.\n\nMaybe we should simply always require pte_write() like we do for\npin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let\u0027s check for\nACRN_MEM_ACCESS_WRITE for now.\n\n(2) We\u0027re not rejecting refcounted pages.\n\nAs we are not using MMU notifiers, messing with refcounted pages is\ndangerous and can result in use-after-free. Let\u0027s make sure to reject them.\n\n(3) We are only looking at the first PTE of a bigger range.\n\nWe only lookup a single PTE, but memmap-\u003elen may span a larger area.\nLet\u0027s loop over all involved PTEs and make sure the PFN range is\nactually contiguous. Reject everything else: it couldn\u0027t have worked\neither way, and rather made use access PFNs we shouldn\u0027t be accessing.",
"id": "GHSA-h3h3-jq7c-xgpc",
"modified": "2025-09-17T18:31:13Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38610"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d6586008f7b638f91f3332602592caa8b00b559"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c6705aa47b5b78d7ad36fea832bb69caa5bf49a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/afeb0e69627695f759fc73c39c1640dbf8649b32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e873f36ec890bece26ecce850e969917bceebbb6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.