CVE-2024-38610: drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
In 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.
Security readout for executives and security teams
Plain-English summary
CVE-2024-38610 is a Linux kernel flaw in the ACRN virtualization driver. The bug involves unsafe memory mapping checks that could let the driver access memory it should not, or trigger use-after-free conditions. It matters mainly for systems using the ACRN driver; there is no cited evidence of active exploitation.
Executive priority
Treat as a targeted kernel maintenance priority, not an internet-wide emergency. Patch ACRN-enabled systems promptly during normal change windows; escalate if ACRN is used in production virtualization platforms.
Technical view
The fix changes drivers/virt/acrn acrn_vm_ram_map() handling of PFNMAP PTEs. The vulnerable logic did not check PTE write permissions, did not reject refcounted pages while lacking MMU notifiers, and checked only the first PTE across larger ranges. The upstream note describes this as dangerous follow_pte()/follow_pfn() usage.
Likely exposure
Exposure appears limited to Linux systems using the ACRN virtualization driver. General Linux servers not using ACRN are less likely to be affected, but kernel builds and distro backports must be verified.
Exploitation context
The public record describes unsafe kernel memory handling, including potential use-after-free and access to unintended PFNs. The bundle marks KEV as false, and no provided source states active exploitation or a public exploit.
Researcher notes
Evidence is limited to the CVE record and kernel stable commits. No CVSS, CWE, exploit status, or vendor-specific package names are provided. The core issue is incomplete PFNMAP PTE validation in acrn_vm_ram_map().
Mitigation direction
Apply a vendor-supported Linux kernel update containing the referenced stable fixes.
Prioritize hosts that use ACRN virtualization or include the ACRN driver.
If no update is available, monitor Linux and distribution advisories for backported fixes.
Avoid assuming fixed status from version strings alone; confirm distro backport status.
Validation and detection
Inventory Linux hosts for ACRN driver usage or enablement.
Compare running kernel packages against vendor advisories and referenced stable commits.
Confirm affected ACRN systems have received the relevant kernel fix.
Document non-ACRN systems as lower exposure after validation.
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-38610 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.