Answer in brief
CVE-2024-38610 records a Unknown severity vulnerability in drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b9c43aa0b18da5619aac347d54cb67fe30d1f884 <5c6705aa47b5b78d7ad36fea832bb69caa5bf49a || >=8a6e85f75a83d16a71077e41f2720c691f432002 <afeb0e69627695f759fc73c39c1640dbf8649b32 || >=8a6e85f75a83d16a71077e41f2720c691f432002 <e873f36ec890bece26ecce850e969917bceebbb6 || >=8a6e85f75a83d16a71077e41f2720c691f432002 <4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4 || >=8a6e85f75a83d16a71077e41f2720c691f432002 <2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb || >=8a6e85f75a83d16a71077e41f2720c691f432002 <3d6586008f7b638f91f3332602592caa8b00b559 || 149d5fb7e0124c3763e92edd1fde19417f4d2d09 || 02098ac42b7ff055ec72cd083ee1eb0a23481a19 || >=5.15.33 <5.15.161 || >=5.16.19 <5.17 || >=5.17.2 <5.18 | 5c6705aa47b5b78d7ad36fea832bb69caa5bf49a, afeb0e69627695f759fc73c39c1640dbf8649b32, e873f36ec890bece26ecce850e969917bceebbb6, 4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4, 2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb, 3d6586008f7b638f91f3332602592caa8b00b559, 5.15.161, 5.17, 5.18 |
| Linux/Linuxgeneric | 5.18 | Not reported |
Published upstream
Jun 19, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2024-38610 records a Unknown severity vulnerability in drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b9c43aa0b18da5619aac347d54cb67fe30d1f884 <5c6705aa47b5b78d7ad36fea832bb69caa5bf49a || >=8a6e85f75a83d16a71077e41f2720c691f432002 <afeb0e69627695f759fc73c39c1640dbf8649b32 || >=8a6e85f75a83d16a71077e41f2720c691f432002 <e873f36ec890bece26ecce850e969917bceebbb6 || >=8a6e85f75a83d16a71077e41f2720c691f432002 <4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4 || >=8a6e85f75a83d16a71077e41f2720c691f432002 <2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb || >=8a6e85f75a83d16a71077e41f2720c691f432002 <3d6586008f7b638f91f3332602592caa8b00b559 || 149d5fb7e0124c3763e92edd1fde19417f4d2d09 || 02098ac42b7ff055ec72cd083ee1eb0a23481a19 || >=5.15.33 <5.15.161 || >=5.16.19 <5.17 || >=5.17.2 <5.18 | 5c6705aa47b5b78d7ad36fea832bb69caa5bf49a, afeb0e69627695f759fc73c39c1640dbf8649b32, e873f36ec890bece26ecce850e969917bceebbb6, 4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4, 2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb, 3d6586008f7b638f91f3332602592caa8b00b559, 5.15.161, 5.17, 5.18 |
| Linux/Linuxgeneric | 5.18 | Not reported |
Published upstream
Jun 19, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.