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: erofs: disable LZ4 rolling
    decompression for now LZ4 rolling decompression [1] was introduced to reduce the memory footprint of
    temporary pages: For many cases, it is needed for users to read small data within a compressed extent
    (pcluster), either due to random small read, or since uptodate folios (typically order-0) cannot be reused
    for decompression again since decompression algorithm refills already-uptodate folios. Rolling
    decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of decompressed
    data, so in theory only a bounded rolling window of temporary pages is needed when decompressing. It can
    save a lot of temporary memory, e.g. 601,960-byte data can be compressed into a 256k LZ4 compressed
    extent, which means it needs 146 extra pages per request in the worst case if rolling decompression is
    disabled. However, the upstream LZ4 implementation is not under EROFS' control: For example, the literal
    copy memmove() may still **copy long literals backward** on x86 based on the address comparison even when
    the source and destination ranges do not overlap (IOWs, inline decompression doesn't need to be considered
    here). That breaks the rolling assumption and makes the optimization broken. Disable it for now to make
    sure the data correctness first since EROFS is used everywhere now: The rolling window approach can be
    revived once we either ensure that the official LZ4 code always copies forward for non-overlapping ranges
    or maintain our own LZ4 implementation in EROFS. The main impact is a higher runtime memory footprint;
    However, recent commit 0f6273ab4637 ("erofs: add a reserved buffer pool for lz4 decompression") helps
    mitigate this when enabled but it's still not perfect. [1]
    https://www.usenix.org/conference/atc19/presentation/gao § 3.3 Decompression (CVE-2026-98067)

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

  - erofs：暫時停用 LZ4 滾動解壓縮 引入 LZ4 滾動解壓縮 [1] 是為了減少臨時頁面的記憶體佔用： 在許多情況下，使用者需要讀取壓縮範圍 （pcluster） 內的小資料，這是由於隨機小讀取，或者因為解壓縮演算法會重新填充已經更新的對開本，因此無法再次重複使用最新的對開本 （通常是 order-0） 進行解壓縮。滾動解壓縮之所以有效，是因為 LZ4 是 LZ77基於 -的，並且僅參考最近 64 KiB 的解壓縮數據，因此理論上解壓縮時只需要臨時頁面的有界滾動視窗。它可以節省大量臨時內存，例如 601,960 位元組的數據可以壓縮成 256k LZ4 壓縮範圍，這意味著在禁用滾動解壓縮的情況下，在最壞的情況下，每個請求需要 146 個額外的頁面。不過，上游 LZ4 實作不受 EROFS 控制：例如，即使來源和目的地範圍不重疊，文字複製 memmove（） 仍可能根據位址比較在 x86 上**向後複製長文字** （IOW，這裡不需要考慮內嵌解壓縮）。這打破了滾動假設並使優化被破壞。暫時停用它以確保資料正確性，因為 EROFS 現在無處不在：一旦我們確保官方 LZ4 程式碼始終向前複製不重疊的範圍，或者在 EROFS 中維護我們自己的 LZ4 實作，滾動視窗方法就可以恢復。主要影響是更高的運行時間內存佔用;不過，最近的提交 0f6273ab4637 （erofs：新增保留的緩衝區集區以進行 lz4 解壓縮） 在啟用時有助於緩解此問題，但它仍然不完美。[1] https://www.usenix.org/conference/atc19/presentation/gao3.3 解壓縮 （CVE-2026-98067）

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

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

  - erofs：暂时禁用 LZ4 滚动解压缩 引入 LZ4 滚动解压缩 [1] 以减少临时页面的内存占用： 在许多情况下，用户需要读取压缩范围 （pcluster） 内的小型数据，这是因为随机小型读取，或是因为解压缩算法会重新填充最新的作品集，而无法再次使用最新的作品集（通常为 order-0）来解压缩。滚动解压缩之所以有效，是因为 LZ4 是 LZ77基于 -并且仅引用最近的 64 KiB 的解压缩数据，因此理论上解压缩时只需要临时页面的有界滚动窗口。它可以节省大量临时内存，例如，601,960 字节的数据可以压缩成 256k LZ4 压缩范围，这意味着在最坏的情况下如果禁用滚动解压缩，每个请求需要额外 146 页。但是，上游 LZ4 实现不受 EROFS 的控制：例如，即使源和目标范围不重叠（IOW，此处不需要考虑内联解压缩），文本复制 memmove（） 仍会根据地址比较在 x86 上**向后复制长文本**。这打破了滚动假设并破坏了优化。暂时禁用它以确保数据正确性，因为现在所有地方都在使用 EROFS：一旦我们确保官方 LZ4 代码始终向前复制非重叠范围，或在 EROFS 中维护我们自己的 LZ4 实现，即可恢复滚动窗口方法。主要影响是更高的运行时内存占用;不过，最近的提交 0f6273ab4637（erofs：为 lz4 解压缩添加保留的缓冲池）在启用时有助于缓解此问题，但仍不完美。[1] https://www.usenix.org/conference/atc19/presentation/gao3.3 解压缩 （CVE-2026-98067）

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

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

  - erofs:今のところ LZ4 ローリング展開を無効にします LZ4 ローリング展開 [1] は、一時ページのメモリフットプリントを低減するために導入されました: 多くの場合、ユーザーは圧縮された範囲(pcluster)内で小さなデータを読み取る必要があります。これは、ランダムな小さな読み取りのためか、または展開アルゴリズムがすでに更新されたフォリオを書き込むため、最新の Folio(通常は order-0)を展開に再度使用できないためです。LZ4 は LZ77 ベースであり、最新の 64 KiB の展開データのみを参照するため、理論的には展開時に一時ページのバウンドされたローリングウィンドウのみが必要なため、ローリング展開は機能します。これにより、一時メモリを大幅に節約できます。例えば、601,960 バイトのデータを 256k LZ4 圧縮範囲に圧縮できます。これは、ローリング展開が無効な場合、最悪の場合、リクエストごとに 146 ページの追加ページが必要になることを意味します。ただし、アップストリームのLZ4実装はEROFSの管理下にありません。たとえば、リテラルコピーのmemmove()は、ソースと宛先の範囲が重複しない場合でも、アドレス比較に基づいてx86で**長いリテラルを後方にコピー**する可能性があります(ここではIOW、インライン展開を考慮する必要はありません)。これにより、ローリングの仮定が破られ、最適化が破られます。EROFS は現在あらゆる場所で使用されているため、まずデータの正確性を確保するために、今のところ無効にしてください。ローリングウィンドウのアプローチは、公式の LZ4 コードが重複しない範囲に対して常に前方にコピーされるようにするか、EROFS で独自の LZ4 実装を維持すると復活できます。主な影響は、ランタイムメモリフットプリントの増加です。ただし、最近のコミット 0f6273ab4637(erofs:lz4 展開用の予約済みバッファプールの追加)が有効にするとこれを緩和できますが、それでも完璧ではありません。[1] https://www.usenix.org/conference/atc19/presentation/gao3.3 解凍(CVE-2026-98067)

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

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

  - erofs: disable LZ4 rolling decompression for now LZ4 rolling decompression [1] was introduced to reduce     the memory footprint of temporary pages: For many cases, it is needed for users to read small data within     a compressed extent (pcluster), either due to random small read, or since uptodate folios (typically     order-0) cannot be reused for decompression again since decompression algorithm refills already-uptodate     folios. Rolling decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of     decompressed data, so in theory only a bounded rolling window of temporary pages is needed when     decompressing. It can save a lot of temporary memory, e.g. 601,960-byte data can be compressed into a 256k     LZ4 compressed extent, which means it needs 146 extra pages per request in the worst case if rolling     decompression is disabled. However, the upstream LZ4 implementation is not under EROFS' control: For     example, the literal copy memmove() may still **copy long literals backward** on x86 based on the address     comparison even when the source and destination ranges do not overlap (IOWs, inline decompression doesn't     need to be considered here). That breaks the rolling assumption and makes the optimization broken. Disable     it for now to make sure the data correctness first since EROFS is used everywhere now: The rolling window     approach can be revived once we either ensure that the official LZ4 code always copies forward for non-     overlapping ranges or maintain our own LZ4 implementation in EROFS. The main impact is a higher runtime     memory footprint; However, recent commit 0f6273ab4637 (erofs: add a reserved buffer pool for lz4     decompression) helps mitigate this when enabled but it's still not perfect. [1]     https://www.usenix.org/conference/atc19/presentation/gao  3.3 Decompression (CVE-2026-98067)

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

ID	Name	Product	Family	Published	Updated	Severity
475331	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Self-Hosted Container Security	Google COS Security Checks	10/16/2026	10/16/2026	medium
475331	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.106	Tenable Cloud Security	Google COS Security Checks	10/16/2026	10/16/2026	medium
350373	Linux Distros 未修補弱點：CVE-2026-98067	Nessus	Misc.	9/25/2026	10/2/2026	medium
350373	Linux Distros 未修补的漏洞：CVE-2026-98067	Nessus	Misc.	9/25/2026	10/2/2026	medium
350373	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98067	Nessus	Misc.	9/25/2026	10/2/2026	medium
350373	Linux Distros Unpatched Vulnerability : CVE-2026-98067	Nessus	Misc.	9/25/2026	10/2/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium

medium

medium