Description
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.
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.
No analysis available yet.
Remediation
No remediation available yet.
Tracking
Sign in to view the affected projects.
Advisories
| Source | ID | Title |
|---|---|---|
Ubuntu USN |
USN-6949-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6949-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6952-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-6955-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-7007-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7007-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7007-3 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7009-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7009-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7019-1 | Linux kernel vulnerabilities |
References
History
Wed, 17 Sep 2025 17:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-416 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Metrics |
cvssV3_1
|
cvssV3_1
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-05-04T12:56:52.947Z
Reserved: 2024-06-18T19:36:34.942Z
Link: CVE-2024-38610
Updated: 2024-08-02T04:12:25.993Z
Status : Analyzed
Published: 2024-06-19T14:15:20.893
Modified: 2025-09-17T17:05:59.960
Link: CVE-2024-38610
OpenCVE Enrichment
Updated: 2025-07-12T22:01:06Z
Ubuntu USN