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

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)

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	Type	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 Cloud Security	Google COS Security Checks	Local	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 Self-Hosted Container Security	Google COS Security Checks	Local	medium
350373	Linux Distros Unpatched Vulnerability : CVE-2026-98067	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-98067

medium

Tenable Plugins

medium

medium

medium