Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - mmuserfaultfduserfaultfd_move と swap キャッシュの競合を修正します このコミットは 2 種類の競合を修正します。異なる結果が生じる可能性があります。Barry 氏はコミット c50f8e6053b0 の BUG_ON を報告しました。ファイルマップ検索が NULL を返し、folio が追加される場合、同じ BUG_ON が確認される場合があります。その後キャッシュをスワップします。別の種類の競合がトリガーされる検索後に folio が変更される場合、RSS カウンターが破損していることがわかります [ 406.893936] バグ rss-counter state が不適切です mm:ffff0000c5a9ddc0 type:MM_ANONPAGES val:-1 [ 406.894071] BUG不適切な rss -counter state mm:ffff0000c5a9ddc0 type:MM_SHMEMPAGES val:1 folio が誤った VMA にアカウントされているため。データ破損が発生するかどうかは不明ですが、発生しないようです。上記の問題はすでに重要度最高です。スワップエントリ PTE を確認すると、userfaultfd_move はロックのないスワップキャッシュ検索を実行し、見つかった folio を障害のある vma に移動しようとします。現在、移動された folio が引き続き src スワップエントリに属し、新しい folio がスワップキャッシュに追加されないように、PTE 値をチェックする必要があります。このため、信頼できないことが判明します。Barry でスワップテーブルシリーズを作業および確認する際、以下の既存の競合が観察され、繰り返されます [1]。以下の例では、move_pages_pte が src_pte を dst_pte に移動しています。ここで src_pte はスワップエントリ S1 を保持しているスワップエントリ PTE であり、S1 は移動しません。スワップキャッシュ内CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // ここで、エントリ = S1 を取得しました ... < 割り込み済み> ...<swapin src_pte, alloc and use folio A> // folio A は新しく割り当てられた folio // で、src_pte にインストールされます <frees swap entry S1> // src_pte は今では folio A、S1 を指すようになりました // スワップカウント == 0 を持ちます。これは解放されます // folio_swap_swap またはスワップ // アロケーター可能性があります。 <try to swap out another folio B> // folio B は別の VMA の folio です。 <put folio B to swap cache using S1 > // S1 が解放され、folio B はこれを使用できます // 問題なくスワップアウトできます。 ... folio = filemap_get_folio(S1) // Get folio B ここで !!! ... < interrupted again> ... <swapin folio B and free S1> // 現在は S1 が再度使用可能です。<swapout src_pte & folio A using S1> // 現在は src_pte はスワップエントリ PTE // であり、再び S1 を保持しています。 folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // src_pte == S1 folio_move_anon_rmap(...) // 無効な folio B をここに移動!!! 競合ウィンドウは非常に短く、複数のまれなイベントの複数の衝突を必要とするため、発生する可能性は非常に低いですが、意図的に構築されたリプリケーターと増加したタイムウィンドウにより、簡単に複製できます。これは、folio ロック取得後に filemap によって返された folio が有効なスワップキャッシュ folio であるかどうかをチェックすることで修正できます。
    別の類似の競合が可能ですfilemap_get_folio は NULL を返す可能性がありますが、folioAがスワップされ、検索後に同じスワップエントリを使用して再びスワップアウトされる可能性があります。このような場合、folio (A) がスワップキャッシュに残る場合もあり、これも移動する必要があります CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // ここでは、エントリ = S1 を取得しています。S1 はスワップキャッシュ folio = filemap_get にありません。
    ---truncated--- (CVE-2025-38242)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - mmuserfaultfd修复 userfaultfd_move 和交换缓存的争用 此提交修复了两种争用它们可能有不同的结果 Barry 报告了提交 c50f8e6053b0 中的一个 BUG_ON如果 filemap 查找返回 NULL 并且添加了 folio 可能会看到相同的 BUG_ON之后再执行此操作以交换缓存。如果触发另一种争用在查找后更改folio可能会发现RSS 计数器已损坏[ 406.893936] BUG不正确 rss-counter state mm:ffff0000c5a9ddc0 type:MM_ANONPAGES val:-1 [ 406.894071] BUG不正确 rss -counter state mm:ffff0000c5a9ddc0 type:MM_SHMEMPAGES val:1 因为 folio 分配给了错误的 VMA。我不确定是否会出现任何数据损坏似乎不会。上述问题已属危急。在发现交换条目 PTE 时userfaultfd_move 会执行 lockless 交换缓存查找并尝试将找到的 folio 移动到出错的 vma。目前，它依赖于对 PTE 值的检查，以确保移动的 folio 仍然属于 src 交换条目，并且没有向交换缓存添加新的 folio，这一点被证明是不可靠的。当使用 Barry 工作和检查交换表系列时会观察到并重现以下现有争用 [1]。在下面的示例中move_pages_pte 将 src_pte 移动到 dst_pte其中 src_pte 是保存交换条目 S1 的交换条目 PTE而 S1 不是交换条目 PTE在交换缓存中的 CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // 此处得到 entry = S1 ... <interrupted> ...<swapin src_pte, alloc and use folio A> // folio A 是新分配的 folio // 并安装到 src_pte 中 <frees swap entry S1> // src_pte 现在指向 folio AS1 // 的交换计数 == 0可以通过 folio_swap_swap 或 swap // 分配器释放回收。 <try to swap out another folio B> // folio B 是另一个 VMA 中的 folio。 <put folio B to swap cache using S1 > // S1 已释放folio B 可将其 // 毫无问题地用于换出。 ... folio = filemap_get_folio(S1) // 此处已获取 folio B ... <中断再次> ... <swapin folio B and free S1> // 现在 S1 可再次使用。<swapout src_pte & folio A using S1> // 现在 src_pte 是交换条目 PTE // 再次持有 S1。 folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // 检查已通过因为 src_pte == S1 folio_move_anon_rmap(...) // 将此无效 folio B 移至此处该争用窗口非常短，需要多个罕见事件的多次冲突，因此不太可能发生，但通过故意构建的重现器和增加的时间窗口，可以轻松重现。这可通过在获取 folio 锁定后检查 filemap 返回的 folio 是否为有效的交换缓存 folio 来修复。
    可能存在另一个类似的争用filemap_get_folio 可能返回 NULL但可使用相同的交换条目将 folio (A) 换入再换出。在这种情况下 folio (A) 可能保留在交换缓存中因此也必须将其移动。 // 此处的条目 = S1且 S1 不在交换缓存中 folio = filemap_get
    ---truncated--- (CVE-2025-38242)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - mmuserfaultfd修正 userfaultfd_move 和 swap 快取的爭用此認可可修正兩種爭用它們可能有不同的結果 Barry 報告認可 c50f8e6053b0 中存在 BUG_ON如果 filemap 查閱傳回 NULL 且已新增作品集我們可能會看到相同的 BUG_ON之後交換快取。如果觸發其他類型的爭用 (產品組合在查閱後變更)我們可能會看到 RSS 計數器已損毀 [ 406.893936] 錯誤rss 計數器狀態錯誤 mm:ffff0000c5a9ddc0 type:MM_ANONPAGES val:-1 [ 406.894071] 錯誤rss 錯誤-counter state mm:ffff0000c5a9ddc0 type:MM_SHMEMPAGES val:1 因為該作品集的 VMA 計量錯誤。不過我不確定是否會有任何資料損毀似乎不會。上述問題已經很嚴重。看到交換項目 PTE 時userfaultfd_move 會執行無鎖定交換快取查閱並嘗試將找到的作品集移至錯誤的 vma。目前它依賴檢查 PTE 值來確保移動的作品集仍屬於 src 交換項目且沒有新的作品集新增至交換快取中而事實證明這是不可靠的。與 Barry 一起研究和檢閱交換錶系列時觀察到並重現了下列現有爭用 [1]在下面的範例中move_pages_pte 將 src_pte 移至 dst_pte其中 src_pte 是保留交換項目 S1 的交換項目 PTE而 S1 不是在交換快取中CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte) // 此處為 entry = S1 ... <中斷> ...<swapin src_pte, alloc and use folio A> // folio A 是新配置的 folio // 並且會安裝到 src_pte <frees swap entry S1> // src_pte 現在指向 folio A S1 // 具有交換計數 == 0其可由 folio_swap_swap 或 swap 釋放 // 配置器回收。 <try to swap out another folio B> // 作品集 B 是另一個 VMA 中的作品集。 <put folio B to swap cache using S1 > // S1 已釋放 folio B 可使用它// 來順利移出。 ... folio = filemap_get_folio(S1) // 此處取得 folio B !!! ... <interrupted Again> ... <swapin folio B and free S1> // 現在 S1 可以再次釋放使用。<swapout src_pte & folio A using S1> // 現在 src_pte 是交換項目 PTE // 再次保持 S1。 folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // 檢查已通過因為 src_pte == S1 folio_move_anon_rmap(...) // 將無效的 folio B 移至此處 !!! 爭用範圍非常短而且需要多個罕見事件的多次沖突因此發生這種情況的可能性很小但是透過刻意建構的複制器和增加的時間範圍可以輕鬆複製它。若要修正此問題則在取得 folio 鎖定之後檢查 filemap 傳回的 folio是否為有效的交換快取 folio。
    可能發生另一個類似的爭用情形filemap_get_folio 可能傳回 NULL但 folio (A) 可被換入然後在查閱之後使用相同的交換項目再次換出。在這種情況下作品集 (A) 可能會保留在交換快取中因此必須將其一併移除// 此處為 entry = S1且 S1 不在交換快取 folio = filemap_get 中
    ---truncated--- (CVE-2025-38242)

請注意，Nessus 依賴供應商報告的套件存在。

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.

ID	Name	Product	Family	Published	Updated	Severity
248907	Linux Distros のパッチ未適用の脆弱性: CVE-2025-38242	Nessus	Misc.	8/12/2025	8/12/2025	medium
248907	Linux Distros 未修补的漏洞：CVE-2025-38242	Nessus	Misc.	8/12/2025	8/12/2025	medium
248907	Linux Distros 未修補的弱點：CVE-2025-38242	Nessus	Misc.	8/12/2025	8/12/2025	medium
248907	Linux Distros Unpatched Vulnerability : CVE-2025-38242	Nessus	Misc.	8/12/2025	8/12/2025	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium