Lucene search

K
nvd416baaa9-dc9f-4396-8d5f-8c081fb06d67NVD:CVE-2024-38610
HistoryJun 19, 2024 - 2:15 p.m.

CVE-2024-38610

2024-06-1914:15:20
416baaa9-dc9f-4396-8d5f-8c081fb06d67
web.nvd.nist.gov
2
linux kernel
acrn driver
pfnmap pte checks
follow pte
vulnerability
patch series
refcounted pages
pte write permissions
mmu notifiers
contiguous pfn range

0.0004 Low

EPSS

Percentile

10.4%

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.

0.0004 Low

EPSS

Percentile

10.4%