Detections
Analytics

Echo: linux: security update to 6.10.11-1

medium Tenable Cloud Security Plugin ID 463023

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

 - In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs
 Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in
 mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check
 is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel
 build with some extra mdelay() calls. See the commit message for a description of the race scenario. On
 older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page
 contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As
 pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page
 tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've
 tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against
 UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5),
 for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested
 that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate
 fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to
 kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following
 race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads
 none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap
 PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in
 a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit
 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than
 a BUG_ON(), since the page table access helpers are actually designed to deal with page tables
 concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past
 the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi
 Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and
 swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic()
 runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it
 will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage
 follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no
 "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is
 no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that
 didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As
 part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's
 redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note:
 pmdp_get_lockless() is pmd_read_atomic() in older kernels. (CVE-2024-46787)

Solution

Update the linux library and its related packages to version 6.10.11-1 or later.

See Also

https://advisory.echohq.com/cve/CVE-2024-46787

Plugin Details

Severity: Medium

ID: 463023

Version: Revision 1.1

Type: Local

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.18

CVSS v2

Risk Factor: Low

Base Score: 3.8

Temporal Score: 2.8

Vector: CVSS2#AV:L/AC:H/Au:S/C:N/I:N/A:C

CVSS Score Source: CVE-2024-46787

CVSS v3

Risk Factor: Medium

Base Score: 4.7

Temporal Score: 4.1

Vector: CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Patch Publication Date: 9/15/2025

Vulnerability Publication Date: 9/18/2024

Reference Information

CVE: CVE-2024-46787