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: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Memory Consumption / Availability
Action: Patch
AI Analysis

Impact

The vulnerability arises from the erofs filesystem’s use of an external LZ4 compression library that was enhanced with a rolling decompression optimisation based on a 64 KiB sliding window. The external LZ4 implementation can perform backward copies of non‑overlapping memory ranges, breaking the rolling assumption. As a result the optimisation was disabled to guarantee correct decompression behaviour, but the change increases the runtime memory footprint of erofs operations.

Affected Systems

All installations of the Linux kernel that include the erofs filesystem are affected. The CVE does not list specific kernel versions; therefore any distribution using erofs, whether as a root or data filesystem, should treat all recent kernel releases containing erofs as potentially impacted until the mitigation is applied.

Risk and Exploitability

The CVSS score is 5.5 and the EPSS score is below 1 %, indicating moderate severity and a very low likelihood of exploitation. The issue is not listed in the CISA KEV catalog. The likely attack vector is local, requiring an attacker to trigger erofs decompression, for example by creating or accessing files on an erofs‑mounted filesystem. No remote exploitation pathway is documented. The primary risk is a higher memory consumption that could affect system performance or stability, while integrity concerns are mitigated by disabling the problematic optimisation.

Generated by OpenCVE AI on September 30, 2026 at 15:13 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the erofs rolling‑decompression disabling patch and the reserved buffer pool addition (commit 0f6273ab4637).
  • Configure kernel parameters to tune the erofs decompression buffer pool size if supported, ensuring memory usage remains within acceptable limits.
  • Monitor system memory usage and kernel logs for excessive erofs decompression activity, setting alerts if thresholds are exceeded.

Generated by OpenCVE AI on September 30, 2026 at 15:13 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 21 Oct 2026 13:15:00 +0000


Tue, 29 Sep 2026 21:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Tue, 29 Sep 2026 13:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-440
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


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-10-21T12:54:21.582Z

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

Link: CVE-2026-98067

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Undergoing Analysis

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

Modified: 2026-10-21T13:21:21.163

Link: CVE-2026-98067

cve-icon Redhat

Severity : Low

Publid Date: 2026-09-25T00:00:00Z

Links: CVE-2026-98067 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-30T15:15:16Z

Weaknesses
  • CWE-440

    Expected Behavior Violation