Description
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
Published: 2026-09-25
Score: n/a
EPSS: n/a
KEV: No
Impact: Data Corruption / Integrity (incorrect decompression) and increased memory usage
Action: Apply patch
AI Analysis

Impact

The vulnerability arises from the integration of the external LZ4 compression library into the Linux kernel’s erofs filesystem. The rolling decompression technique relies on a 64 KiB sliding window of decompressed data, but the upstream LZ4 implementation can copy memory backwards when source and destination ranges do not overlap, thereby breaking the rolling assumption. When this occurs the filesystem may produce corrupted data or, at the very least, incur a higher runtime memory footprint. The developers resolved the issue by disabling LZ4 rolling decompression for the time being and introducing a reserved buffer pool to mitigate the memory cost. The main impact is a potential loss of data integrity and an elevated memory requirement for erofs operations.

Affected Systems

All installations employing the Linux kernel’s erofs filesystem are affected. This includes any distribution that uses erofs as its root or data filesystem. No specific kernel versions are listed in the CVE; administrators should treat all recent kernel releases that include erofs as potentially impacted until a patch is applied.

Risk and Exploitability

The CVSS score is not provided, and the EPSS is unavailable, indicating limited available exploitation data. The vulnerability has not been listed in the CISA KEV catalog. The likely attack vector is local, requiring the attacker to manipulate or trigger erofs decompression operations (e.g., via crafted files). Because the issue is an implementation flaw that can corrupt data, the risk is medium to high for affected systems, particularly those with sensitive or critical data stored in erofs. No remote exploitation path has been documented, but the integrity impact warrants prompt remediation.

Generated by OpenCVE AI on September 25, 2026 at 15:41 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Install the latest Linux kernel that includes the erofs rolling decompression fix and the reserved buffer pool patch (commit 0f6273ab4637).
  • Verify the integrity of erofs-mounted filesystems with fsck or similar utilities to detect corruption.
  • Monitor system memory usage and logs for signs of excessive decompression memory or unexpected warnings that may indicate persistent decompression issues.

Generated by OpenCVE AI on September 25, 2026 at 15:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 25 Sep 2026 16:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Description 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
Title erofs: disable LZ4 rolling decompression for now
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-25T10:24:09.610Z

Reserved: 2026-09-25T10:19:56.074Z

Link: CVE-2026-98067

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:35.787

Modified: 2026-09-25T11:17:35.787

Link: CVE-2026-98067

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T15:45:19Z

Weaknesses
  • CWE-119

    Improper Restriction of Operations within the Bounds of a Memory Buffer