https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 01:43:27 +0000 https://vulnerability.circl.lu/vuln/cve-2026-98067 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>erofs: disable LZ4 rolling decompression for now</p> <p>LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages:</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>However, the upstream LZ4 implementation is not under EROFS&#39; 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&#39;t need to be considered here). That breaks the rolling assumption and makes the optimization broken.</p> <p>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…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>erofs: disable LZ4 rolling decompression for now</p> <p>LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages:</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>However, the upstream LZ4 implementation is not under EROFS&#39; 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&#39;t need to be considered here). That breaks the rolling assumption and makes the optimization broken.</p> <p>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…</p> https://vulnerability.circl.lu/vuln/cve-2026-98067