CVE-2024-38610 Affecting kernel-syms package, versions <6.4.0-150600.23.14.2
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-SLES156-KERNELSYMS-7553905
- published 23 Jul 2024
- disclosed 22 Jul 2024
Introduced: 22 Jul 2024
CVE-2024-38610 Open this link in a new tabHow to fix?
Upgrade SLES:15.6 kernel-syms to version 6.4.0-150600.23.14.2 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-syms package and not the kernel-syms package as distributed by SLES.
See How to fix? for SLES:15.6 relevant fixed versions and status.
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.
References
- https://www.suse.com/security/cve/CVE-2024-38610.html
- https://bugzilla.suse.com/1226758
- https://bugzilla.suse.com/1227284
- https://git.kernel.org/stable/c/2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb
- https://git.kernel.org/stable/c/3d6586008f7b638f91f3332602592caa8b00b559
- https://git.kernel.org/stable/c/4c4ba3cf3a15ccfbaf787d0296fa42cdb00da9b4
- https://git.kernel.org/stable/c/5c6705aa47b5b78d7ad36fea832bb69caa5bf49a
- https://git.kernel.org/stable/c/afeb0e69627695f759fc73c39c1640dbf8649b32
- https://git.kernel.org/stable/c/e873f36ec890bece26ecce850e969917bceebbb6