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

  - riscv：修補程式：修正對 bpf-jit execmem 位址的處理 提交 8718e5a3090b （riscv：修補程式：當核心文字已可寫入時跳過 fixmap 映射） 在 CONFIG_STRICT_KERNEL_RWX 上限制了 patch_map（） 的 core_kernel_text（） 分支，並明確保持 vmalloc 分支不變。該分支有一個單獨的問題。該分支只會在啟用CONFIG_STRICT_MODULE_RWX時建立暫時可寫入的固定對應別名，否則會假設目標可直接寫入，並傳回不變的位址。這個假設不再成立：bpf_prog_pack_alloc在 alloc_new_pack（） 中無條件地呼叫每個套件上的 set_memory_rox（），與任何 CONFIG_STRICT_*_RWX 選項無關，因此無論 CONFIG_STRICT_MODULE_RWX 說什麼，vmalloc 區域中的 BPF 文字都是唯讀的。當 CONFIG_STRICT_MODULE_RWX=n 時，patch_map（） 直接傳回唯讀位址，後續的 copy_to_kernel_nofault（） 會發生頁面錯誤並傳回 -EFAULT。bpf_arch_text_copy（） 將其轉換為 -EINVAL，它透過 bpf_jit_binary_pack_finalize（） 傳播到 bpf_int_jit_compile（） 中的 WARN_ON（），並使程式未進行 JIT。
    請注意，BPF 無法像 kprobes 在提交 bdc46e507b59 中那樣修復 （riscv：mm：使EXECMEM_KPROBES無需CONFIG_STRICT_MODULE_RWX即可寫入）。EXECMEM_BPF已經PAGE_KERNEL，即在分配時可寫入;唯讀映射隨後由 alloc_new_pack（） 中的通用程式碼建立，arch 程式碼無法影響。唯一可以處理的地方是 patch_map（）。這與提交 b1480ed230ac 在 arm64 上修正的問題相同 （arm64：修補：修正 execmem 位址的處理），而且修正是相同的：CONFIG_EXECMEM 是實際追蹤 vmalloc 區域是否可以容納需要寫入臨時別名的可執行記憶體的內容。CONFIG_BPF_JIT、CONFIG_KPROBES和CONFIG_MODULES都選取它。請注意，這不限於 CONFIG_MODULES=n。與 arm64 不同，riscv 選擇 CONFIG_ARCH_OPTIONAL_KERNEL_RWX，因此也可以使用 CONFIG_MODULES=y 禁用CONFIG_STRICT_MODULE_RWX，並且在該配置中也可以訪問該錯誤。！CONFIG_MMU 組建不受影響：它有自己的 __patch_insn_set（） 和 __patch_insn_write（） 實作，並且從不呼叫 patch_map（）。
    (CVE-2026-99092)

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

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

  - riscv：修补程序：修复 bpf-jit execmem 地址处理 提交 8718e5a3090b（riscv：修补程序：内核文本已可写入时跳过 fixmap 映射）在 CONFIG_STRICT_KERNEL_RWX 上限制 patch_map（） 的 core_kernel_text（） 分支，明确保持 vmalloc 分支不变。该分支有一个单独的问题。该分支仅在启用CONFIG_STRICT_MODULE_RWX时创建临时可写 fixmap 别名，否则会假定目标可直接写入，并返回原封不动的地址。该假设不再成立：bpf_prog_pack_alloc 会在 alloc_new_pack（） 中无条件地调用每个包上的 set_memory_rox（），不依赖任何 CONFIG_STRICT_*_RWX 选项，因此无论 CONFIG_STRICT_MODULE_RWX 说什么，vmalloc 区域中的 BPF 文本都是只读的。CONFIG_STRICT_MODULE_RWX=n 时，patch_map（） 会直接返回只读地址，后续的 copy_to_kernel_nofault（） 会发生页面错误并返回 -EFAULT。bpf_arch_text_copy（） 将其转换为 -EINVAL，后者通过 bpf_jit_binary_pack_finalize（） 传播到 bpf_int_jit_compile（） 中的 WARN_ON（），并使程序处于非 JIT 状态。
    请注意，无法以 kprobes 在提交 bdc46e507b59 时的方式修复 BPF（riscv：mm：使 EXECMEM_KPROBES 无需CONFIG_STRICT_MODULE_RWX即可写入）。EXECMEM_BPF 已PAGE_KERNEL，即在分配时可写;之后由 alloc_new_pack（） 中的通用代码建立只读映射，arch 代码无法影响。唯一可以处理此漏洞的位置是 patch_map（）。这与提交 b1480ed230ac 在 arm64 上通过提交 b1480ed230ac 修复的问题相同（arm64：修补程序：修复 execmem 地址的处理），修复程序是相同的：CONFIG_EXECMEM实际用于追踪 vmalloc 区域是否可以容纳需要写入临时别名的可执行内存。CONFIG_BPF_JIT、CONFIG_KPROBES 和 CONFIG_MODULES 都选择它。请注意，这不限制为 CONFIG_MODULES=n。与 arm64 不同，riscv 选择CONFIG_ARCH_OPTIONAL_KERNEL_RWX，因此也可以通过 CONFIG_MODULES=y 禁用CONFIG_STRICT_MODULE_RWX，并且该配置中也可以访问该缺陷。！CONFIG_MMU 版本不受影响：它有自己的 __patch_insn_set（） 和 __patch_insn_write（） 实现，并且从不调用 patch_map（）。
    (CVE-2026-99092)

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

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

  - riscv:パッチ:bpf-jit execmem アドレスの処理を修正 コミット 8718e5a3090b(riscv:パッチ:カーネルテキストが既に書き込み可能な場合、fixmap マッピングをスキップ)が CONFIG_STRICT_KERNEL_RWX の patch_map() の core_kernel_text() ブランチにゲートを行い、vmalloc ブランチを明示的に変更せず放置しました。そのブランチには別の問題があります。このブランチは、CONFIG_STRICT_MODULE_RWX有効化されている場合にのみ、一時的に書き込み可能な fixmap エイリアスを作成し、それ以外の場合はターゲットが直接書き込み可能であると想定し、アドレスを変更せずに返します。この前提はもはや成立しません:bpf_prog_pack_alloc は、CONFIG_STRICT_*_RWX オプションとは無関係に、alloc_new_pack() ですべてのパックで set_memory_rox() を無条件に呼び出すため、vmalloc 領域の BPF テキストは、CONFIG_STRICT_MODULE_RWX が何を言っているかにかかわらず読み取り専用です。CONFIG_STRICT_MODULE_RWX=n の場合、patch_map() は読み取り専用アドレスを直接返し、後続の copy_to_kernel_nofault() はページフォルトを受け取り、-EFAULT を返します。bpf_arch_text_copy() はそれを -EINVAL に変え、bpf_jit_binary_pack_finalize() を介して bpf_int_jit_compile() の WARN_ON() に伝播し、プログラムを JIT しないままにします。
    注意:kprobes がコミット bdc46e507b59 であったように BPF を修正することはできません(riscv: mm: EXECMEM_KPROBES をCONFIG_STRICT_MODULE_RWXなしに書き込み可能にします)。EXECMEM_BPFはすでにPAGE_KERNEL、つまり割り当て時に書き込み可能です。読み取り専用マッピングは、後で alloc_new_pack() のジェネリックコードによって確立されますが、アーチコードは影響を及ぼすことはできません。これを処理できる唯一の場所は patch_map() です。これは、コミット b1480ed230ac により arm64 上で修正されたものと同じ問題(arm64:パッチ適用:execmem アドレスの処理を修正)であり、修正も同じです:CONFIG_EXECMEM は、vmalloc 領域が、一時エイリアスの書き込みを必要とする実行可能メモリを保持できるかどうかを実際に追跡するものです。CONFIG_BPF_JIT、CONFIG_KPROBES、CONFIG_MODULES全員が選択します。これは CONFIG_MODULES=n に限定されないことに注意してください。arm64 とは異なり、riscv は CONFIG_ARCH_OPTIONAL_KERNEL_RWX を選択するため、CONFIG_MODULES=y でCONFIG_STRICT_MODULE_RWXも無効にでき、この構成でもバグに到達できます。!CONFIG_MMUビルドは影響を受けず、独自の__patch_insn_set()実装と__patch_insn_write()実装があり、patch_map()を呼び出しません。
    (CVE-2026-99092)

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

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

  - riscv: patch: fix handling of bpf-jit execmem addresses Commit 8718e5a3090b (riscv: patch: skip fixmap     mapping when kernel text is already writable) gated the core_kernel_text() branch of patch_map() on     CONFIG_STRICT_KERNEL_RWX, and explicitly left the vmalloc branch unchanged. That branch has a separate     problem. That branch only creates a temporary writable fixmap alias when CONFIG_STRICT_MODULE_RWX is     enabled, and otherwise assumes the target is directly writable and returns the address unchanged. That     assumption no longer holds: bpf_prog_pack_alloc calls set_memory_rox() on every pack unconditionally in     alloc_new_pack(), independently of any CONFIG_STRICT_*_RWX option, so BPF text in the vmalloc area is     read-only regardless of what CONFIG_STRICT_MODULE_RWX says. With CONFIG_STRICT_MODULE_RWX=n, patch_map()     returns the read-only address directly, the subsequent copy_to_kernel_nofault() takes a page fault and     returns -EFAULT. bpf_arch_text_copy() turns that into -EINVAL, which propagates through     bpf_jit_binary_pack_finalize() to the WARN_ON() in bpf_int_jit_compile() and leaves the program un-JITed.
    Note that BPF cannot be fixed the way kprobes was in commit bdc46e507b59 (riscv: mm: make EXECMEM_KPROBES     writable without CONFIG_STRICT_MODULE_RWX). EXECMEM_BPF is already PAGE_KERNEL, i.e. writable at     allocation time; the read-only mapping is established afterwards by generic code in alloc_new_pack(),     which arch code cannot influence. The only place this can be handled is patch_map(). This is the same     problem that was fixed on arm64 by commit b1480ed230ac (arm64: patching: fix handling of execmem     addresses), and the fix is the same: CONFIG_EXECMEM is what actually tracks whether the vmalloc area can     hold executable memory that needs a temporary alias to be written. CONFIG_BPF_JIT, CONFIG_KPROBES and     CONFIG_MODULES all select it. Note that this is not limited to CONFIG_MODULES=n. Unlike arm64, riscv     selects CONFIG_ARCH_OPTIONAL_KERNEL_RWX, so CONFIG_STRICT_MODULE_RWX can be disabled with CONFIG_MODULES=y     as well, and the bug is reachable in that configuration too. The !CONFIG_MMU build is unaffected: it has     its own __patch_insn_set() and __patch_insn_write() implementations and never calls patch_map().
    (CVE-2026-99092)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
372159	Linux Distros 未修補弱點：CVE-2026-99092	Nessus	Misc.	2026/10/26	2026/10/28	high
372159	Linux Distros 未修补的漏洞：CVE-2026-99092	Nessus	Misc.	2026/10/26	2026/10/28	high
372159	Linux Distros のパッチ未適用の脆弱性: CVE-2026-99092	Nessus	Misc.	2026/10/26	2026/10/28	high
372159	Linux Distros Unpatched Vulnerability : CVE-2026-99092	Nessus	Misc.	2026/10/26	2026/10/28	high

偵測

搜尋 Plugin

high

high

high

high