The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - mm: userfaultfd: fix race of userfaultfd_move and swap cache This commit fixes two kinds of races, they     may have different results: Barry reported a BUG_ON in commit c50f8e6053b0, we may see the same BUG_ON if     the filemap lookup returned NULL and folio is added to swap cache after that. If another kind of race is     triggered (folio changed after lookup) we may see RSS counter is corrupted: [ 406.893936] BUG: Bad rss-     counter state mm:ffff0000c5a9ddc0 type:MM_ANONPAGES val:-1 [ 406.894071] BUG: Bad rss-counter state     mm:ffff0000c5a9ddc0 type:MM_SHMEMPAGES val:1 Because the folio is being accounted to the wrong VMA. I'm     not sure if there will be any data corruption though, seems no. The issues above are critical already. On     seeing a swap entry PTE, userfaultfd_move does a lockless swap cache lookup, and tries to move the found     folio to the faulting vma. Currently, it relies on checking the PTE value to ensure that the moved folio     still belongs to the src swap entry and that no new folio has been added to the swap cache, which turns     out to be unreliable. While working and reviewing the swap table series with Barry, following existing     races are observed and reproduced [1]: In the example below, move_pages_pte is moving src_pte to dst_pte,     where src_pte is a swap entry PTE holding swap entry S1, and S1 is not in the swap cache: CPU1 CPU2     userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1 ... <     interrupted> ... <swapin src_pte, alloc and use folio A> // folio A is a new allocated folio // and get     installed into src_pte <frees swap entry S1> // src_pte now points to folio A, S1 // has swap count == 0,     it can be freed // by folio_swap_swap or swap // allocator's reclaim. <try to swap out another folio B> //     folio B is a folio in another VMA. <put folio B to swap cache using S1 > // S1 is freed, folio B can use     it // for swap out with no problem. ... folio = filemap_get_folio(S1) // Got folio B here !!! ... <     interrupted again> ... <swapin folio B and free S1> // Now S1 is free to be used again. <swapout src_pte &     folio A using S1> // Now src_pte is a swap entry PTE // holding S1 again. folio_trylock(folio)     move_swap_pte double_pt_lock is_pte_pages_stable // Check passed because src_pte == S1     folio_move_anon_rmap(...) // Moved invalid folio B here !!! The race window is very short and requires     multiple collisions of multiple rare events, so it's very unlikely to happen, but with a deliberately     constructed reproducer and increased time window, it can be reproduced easily. This can be fixed by     checking if the folio returned by filemap is the valid swap cache folio after acquiring the folio lock.
    Another similar race is possible: filemap_get_folio may return NULL, but folio (A) could be swapped in and     then swapped out again using the same swap entry after the lookup. In such a case, folio (A) may remain in     the swap cache, so it must be moved too: CPU1 CPU2 userfaultfd_move move_pages_pte() entry =     pte_to_swp_entry(orig_src_pte); // Here it got entry = S1, and S1 is not in swap cache folio = filemap_get
    ---truncated--- (CVE-2025-38242)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2025-38242

medium Nessus Plugin ID 248907

Version 1.6

Version 1.3

Version 1.2

Version 1.1

Version 1.6 Oct 27, 2025, 3:15 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202510271515
Version 1.3 Sep 3, 2025, 4:10 PM CVSS metrics ("Cvssv4 score" set to 0.0) CVSSv2 severity (based on None, severity decreased from "High" to "Low") Detection (updated detection logic) Plugin metadata Plugin Feed: 202509031610
Version 1.2 Aug 31, 2025, 9:16 AM CVSS metrics ("Cvssv4 score" set to 0.0) CVSSv2 severity (based on None, severity decreased from "High" to "Low") Detection (updated detection logic) Plugin metadata Plugin Feed: 202508310916
Version 1.1 Aug 13, 2025, 7:42 PM New Plugin Feed: 202508131942