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

  - mm/vma修复 mremap() 上发生错误、无错误的合并上的 anon_vma UAF 修补程序系列 mm/vma修复 mremap() 上发生错误、无错误的合并上的 anon_vma UAF v2.0 提交 879bca0a2c4fmm/vma修复错误地禁止的匿名 VMA 合并引入了合并之前不可用的 VMA 合并场景的功能。但是当涉及到与未发生故障的 VMA 邻近的发生故障的 VMA 的 mremap() 时其会错误地处理合并。会在三种情况下出现这些问题1。上一个 VMA 无故障：复制 -----| v |------------|----------------| |无故障 |（故障 VMA）| |-----------|........|上一个 2。下一个 VMA 无故障：已复制 -----| v |........|--------| |故障 VMA|无故障 | |......|-----------| 3.两个邻近的 VMA unfaulted: 复制 -----| v |-----------|----------------|--------| |无故障 |（故障 VMA）|无故障 | |------------|........|---------|上一个 下一个 本系列修复了所有这些情况并引入自测试以断言问题已修正。我还进一步测试了已处理的情况以断言我的更改会继续正确地处理它4. prev unfaulted, next Faulted:内容已复制 -----| v |-----------|----------------|--------| |无故障 |（故障 VMA）|错误 | |------------|........|---------| prev next 此缺陷是通过 系列的第一个修补程序中链接的 syzbot 报告发现的。我确认此系列会修复此缺陷。我还发现在上述情况 1-3 中合并复制的 VMA 时我们无法检查有问题的 VMA 是否未 fork此系列问题也将解决该问题。我还添加了自我测试以断言此问题已解决（并确认测试在此之前已失败）。作为这项工作的一部分我还清理了 vma_expand()将 vma_ad_uncowed_parents() 重命名为 vma_is_fork_child()因为之前的名称过于混乱并且简化了与此函数相关的注释。此修补程序共 4 个提交 879bca0a2c4fmm/vma修复错误地禁止匿名 VMA 合并引入了合并以前不可用的 VMA 合并场景的功能。引入的关键逻辑是能够立即将有错误的 VMA 合并到无错误的 VMA 旁边从而依赖 dup_anon_vma() 正确处理 anon_vma 状态。合并现有 VMA即 VMA 的属性由邻近 VMA 共享则更改后合并这些属性会正确调用 dup_anon_vma()。但是在合并新 VMA 时会错过 mremap() 特有的极端情况。问题在于 vma_expand() 仅在目标 VMA 最终成为合并的 VMA满足以下条件时执行 dup_anon_vma() 不是下一个 VMA即在建立新 VMA 的范围之后出现的 VMA 。此处要点在于，在除 mremap() 以外的所有其他情况下，新的 VMA 合并要么扩展现有 VMA，要么使 anon_vma 为空即目标 VMA 将为该 VMA。特别是* __mmap_region() - 未部署 anon_vma初始映射。 * do_brk_flags() - 扩展现有 VMA。 * vma_merge_extend() - 扩展现有 VMA。 * relocate_vma_down() - 未到位 anon_vma初始映射。此外我们遇到一个特殊情况需要从既不是要合并的上一个也不是下一个 VMA 的 VMA 复制 anon_vma 状态。 dup_anon_vma() 专门处理 target=unfaulted、 src=faulted 情况。因此就有四种可能性每种情况下复制的 VMA 会发生故障1. 上一个无故障的 VMA复制了 -----| ---truncated--- (CVE-2026-23077)

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

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

  - mm/vma修正 mremap() 錯誤上無錯誤的 anon_vma UAF 修補程式系列 mm/vma修正 mremap() 錯誤上之 anon_vma UAFv2。認可 879bca0a2c4f (mm/vma修正錯誤禁止的匿名 VMA 合併) 引入了合併先前無法提供之 VMA 合併狀況的功能。不過當發生錯誤的 VMA 與未發生錯誤的 VMA 相鄰時它會不正確地處理合併。此問題會在下列三種情況下發生： 1. 先前的 VMA 未出錯：已復制 -----| v |-----------|........| | unfaulted |(faulted VMA)| |-----------|........| prev 2. Next VMA unfaulted已復制 -----| v |..|-----------| |(錯誤的 VMA)|完整 | |........|-----------| 3. 相鄰的兩個 VMA 都沒有錯誤：已復制 -----| v |-----------|........|------------| | unfaulted |(faulted VMA)|完整 | |-----------|........|------------| prev next 本系列可修正上述每一種情況，並引入自我測試，以宣告問題已更正。我也測試了已處理過的其他案例以宣告我的變更會繼續正確處理： 4. 上一個未出錯，下一個出錯：已復制 -----| v |-----------|........|------------| | unfaulted |(faulted VMA)|錯誤 | |-----------|........|------------| prev next 此錯誤是透過 syzbot 報告所發現該報告連結至 系列的第一個修補程式我確認此系列可修正該錯誤。我也發現在上述案例 1-3 中合併複製的 VMA 時我們無法檢查發生錯誤的 VMA 是否未分叉這本系列文章也會解決這個問題。我也新增了自我測試以宣告此問題已解決 (並在此之前確認測試失敗)。我也在此工作中清理了 vma_expand()、因先前的名稱過於混亂而將 vma_had_uncowed_parents() 重新命名為 vma_is_fork_child()並簡化了有關此函式的註解。此修補程式 (共 4 個) 認可 879bca0a2c4f (mm/vma修正錯誤禁止的匿名 VMA 合併) 引入了合併先前無法使用之 VMA 合併狀況的功能。引入的主要邏輯部分是能夠立即在未發生錯誤的 VMA 旁邊合併發生錯誤的 VMA進而仰賴 dup_anon_vma() 來正確處理 anon_vma 狀態。合併現有 VMA 時 (即變更 VMA 的內容如果相鄰 VMA 共用這些內容則進行合併)dup_anon_vma() 會正確叫用。不過在合併新 VMA 時會遺漏 mremap() 特有的一個邊角案例。問題在於如果目標 (最終將成為合併 VMA 的 VMA): 不是下一個 VMA亦即出現在要建立新 VMA 的範圍之後的 VMA則 vma_expand() 只會執行 dup_anon_vma() 。這裡有一個重要見解是在 mremap() 以外的所有其他情況下新的 VMA 合併會擴充現有的 VMA這表示目標 VMA 將是該 VMA或會使 anon_vma 為 NULL。具體而言* __mmap_region() - anon_vma 到位無初始對應。 * do_brk_flags() - 擴充現有 VMA。 * vma_merge_extend() - 擴充現有的 VMA。 * relocate_vma_down() - anon_vma 到位無初始對應。此外我們還有需要從 VMA 複製 anon_vma 狀態的特殊情況該 VMA 既不是要合併的上一個 VMA 也不是下一個要合併的 VMA。 dup_anon_vma() 專門針對 target=unfaulted、 src=faulted 情況。在所複製的 VMA 發生錯誤的每一種情況下這都會留下四種可能性1. 先前的 VMA 未錯誤已復制 -----| ---truncated--- (CVE-2026-23077)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

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

  - mm/vmamremap() に障害がある、障害のないマージの anon_vma UAF を修正します。パッチシリーズ mm/vmamremap() に障害がある、障害のないマージ、v2 の anon_vma UAF を修正します。コミット 879bca0a2c4fmm/vma誤って許可された匿名の VMA マージを修正で、以前は利用できなかった VMA マージシナリオをマージする機能が導入されました。しかし、障害が発生していない VMA に隣接する障害のある VMA の mremap() に関しては、マージを不適切に処理しています。この問題は 3 つの場合で発生します 1. 以前の VMA が違反である場合 コピーされた -----| v |-----------|....| |障害なし |(障害のある VMA)| |---------------------------| prev 2. 次の VMA が障害のない状態でコピーされました -----| v |....|-----------| |(障害のある VMA)|障害が発生していない | |----------------|-----------|次の 3. 両方の隣接する VMA が障害を受けませんコピーされた -----| v |-----------|.....|-----------| |障害なし |(障害のある VMA)|障害が発生していない | |-----------|----------------|-----------| prev next このシリーズはこれらのケースのそれぞれを修正し、問題が修正されたことをアサートするための自己テストを導入します。また、既に処理された追加のケースをテストし、変更が引き続き適切に処理されることを確認します。4. 前に障害があり、次の障害があります。コピーされました -----| v |-----------|.....|-----------| |障害なし |(障害のある VMA)|障害が発生しました | |-----------|----------------|-----------| prev next このバグは syzbot レポートを通じて発見され、 シリーズの最初のパッチでリンクされています。I はこのシリーズがこのバグを修正することを確認しました。さらに、上記のケース 13 で、コピーされた VMA をマージする際に、障害のある VMA が fork されなかったことをチェックできないことも判明しました。これは、このシリーズでも対処されている問題です。また、これが解決されたことをアサーションするために、自己テストも追加しましたまた、この問題を修正する前にテストが失敗したことを確認しました。また、この作業の一部として vma_expand() をクリーンアップし、以前の名前が非常に混乱を招くために vma_had_uncowed_parents() を vma_is_fork_child() に変更し、この関数に関するコメントを簡素化しました。このパッチ4 のコミット 879bca0a2c4fmm/vma誤って許可されていた匿名の VMA マージを修正により、以前は利用できなかった VMA マージシナリオをマージする機能が導入されました。導入された重要なロジック部分は、障害のある VMA を障害のない VMA のすぐ横にマージする機能でした。これは、anon_vma 状態を正しく処理するために dup_anon_vma() に依存しています。既存の VMA のマージVMA のプロパティを変更し、それらのプロパティが隣接する VMA により共有されている場合はマージする場合、dup_anon_vma() が正しく呼び出されます。しかし、新しい VMA のマージの際、mremap() に特有のコーナーケースがありませんでした。問題は、ターゲット最終的にマージされた VMA になる VMAが次の VMA でない場合、つまり新しい VMA が確立される範囲の後に表示される VMA の場合、 vma_expand() が dup_anon_vma() だけを実行することです。 。ここで重要な洞察は、mremap() 以外のすべての場合では、新しい VMA マージは既存の VMA を拡張する、つまりターゲット VMA がその VMA になるか、anon_vma が NULL になるというものです。具体的には、* __mmap_region() - anon_vma が配置されておらず、初期マッピング。 * do_brk_flags() - 既存の VMA を拡張。 * vma_merge_extend() - 既存の VMA の拡張。 * relocate_vma_down() - anon_vma が配置されず、初期マッピング。さらに、マージされている前後の VMA 以外の VMA から anon_vma 状態を複製する必要があるという特殊な状況にあります。 dup_anon_vma() は target=unfaulted、 src=faulted のケースのみに対処します。これにより、コピーされた VMA に障害が発生するそれぞれの事例で、4 つの可能性が残ります。 1. 以前の VMA が障害のない状態: コピーされた -----| ---truncated---CVE-2026-23077

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

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

  - mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge Patch series mm/vma: fix anon_vma UAF on     mremap() faulted, unfaulted merge, v2. Commit 879bca0a2c4f (mm/vma: fix incorrectly disallowed anonymous     VMA merges) introduced the ability to merge previously unavailable VMA merge scenarios. However, it is     handling merges incorrectly when it comes to mremap() of a faulted VMA adjacent to an unfaulted VMA. The     issues arise in three cases: 1. Previous VMA unfaulted: copied -----| v |-----------|.............| |     unfaulted |(faulted VMA)| |-----------|.............| prev 2. Next VMA unfaulted: copied -----| v     |.............|-----------| |(faulted VMA)| unfaulted | |.............|-----------| next 3. Both adjacent     VMAs unfaulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)|     unfaulted | |-----------|.............|-----------| prev next This series fixes each of these cases, and     introduces self tests to assert that the issues are corrected. I also test a further case which was     already handled, to assert that my changes continues to correctly handle it: 4. prev unfaulted, next     faulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| faulted |     |-----------|.............|-----------| prev next This bug was discovered via a syzbot report, linked to     in the first patch in the series, I confirmed that this series fixes the bug. I also discovered that we     are failing to check that the faulted VMA was not forked when merging a copied VMA in cases 1-3 above, an     issue this series also addresses. I also added self tests to assert that this is resolved (and confirmed     that the tests failed prior to this). I also cleaned up vma_expand() as part of this work, renamed     vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was unduly confusing, and simplified     the comments around this function. This patch (of 4): Commit 879bca0a2c4f (mm/vma: fix incorrectly     disallowed anonymous VMA merges) introduced the ability to merge previously unavailable VMA merge     scenarios. The key piece of logic introduced was the ability to merge a faulted VMA immediately next to an     unfaulted VMA, which relies upon dup_anon_vma() to correctly handle anon_vma state. In the case of the     merge of an existing VMA (that is changing properties of a VMA and then merging if those properties are     shared by adjacent VMAs), dup_anon_vma() is invoked correctly. However in the case of the merge of a new     VMA, a corner case peculiar to mremap() was missed. The issue is that vma_expand() only performs     dup_anon_vma() if the target (the VMA that will ultimately become the merged VMA): is not the next VMA,     i.e. the one that appears after the range in which the new VMA is to be established. A key insight here is     that in all other cases other than mremap(), a new VMA merge either expands an existing VMA, meaning that     the target VMA will be that VMA, or would have anon_vma be NULL. Specifically: * __mmap_region() - no     anon_vma in place, initial mapping. * do_brk_flags() - expanding an existing VMA. * vma_merge_extend() -     expanding an existing VMA. * relocate_vma_down() - no anon_vma in place, initial mapping. In addition, we     are in the unique situation of needing to duplicate anon_vma state from a VMA that is neither the previous     or next VMA being merged with. dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted     case. This leaves four possibilities, in each case where the copied VMA is faulted: 1. Previous VMA     unfaulted: copied -----| ---truncated--- (CVE-2026-23077)

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

ID	Name	Product	Family	Published	Updated	Severity
297931	Linux Distros 未修补的漏洞：CVE-2026-23077	Nessus	Misc.	2/4/2026	7/31/2026	high
297931	Linux Distros 未修補的弱點：CVE-2026-23077	Nessus	Misc.	2/4/2026	7/31/2026	high
297931	Linux Distros のパッチ未適用の脆弱性: CVE-2026-23077	Nessus	Misc.	2/4/2026	7/31/2026	high
297931	Linux Distros Unpatched Vulnerability : CVE-2026-23077	Nessus	Misc.	2/4/2026	7/31/2026	high

Detections

Analytics

Plugins Search

high

high

high

high