{"id":29222,"date":"2026-09-25T20:32:10","date_gmt":"2026-09-25T12:32:10","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98067"},"modified":"2026-09-25T20:32:10","modified_gmt":"2026-09-25T12:32:10","slug":"cve-2026-98067","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-98067","title":{"rendered":"CVE-2026-98067 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: disable LZ4 ro"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>erofs: disable LZ4 rolling decompression for now<\/p>\n<p>LZ4 rolling decompression [1] was introduced to reduce the memory<br \/>\nfootprint of temporary pages:<\/p>\n<p> For many cases, it is needed for users to read small data within<br \/>\n a compressed extent (pcluster), either due to random small read, or<br \/>\n since uptodate folios (typically order-0) cannot be reused for<br \/>\n decompression again since decompression algorithm refills<br \/>\n already-uptodate folios.<\/p>\n<p>Rolling decompression works because LZ4 is LZ77-based and only refers<br \/>\nto the most recent 64 KiB of decompressed data, so in theory only a<br \/>\nbounded rolling window of temporary pages is needed when decompressing.<\/p>\n<p>It can save a lot of temporary memory, e.g.<br \/>\n 601,960-byte data can be compressed into a 256k LZ4 compressed extent,<br \/>\n which means it needs 146 extra pages per request in the worst case if<br \/>\n rolling decompression is disabled.<\/p>\n<p>However, the upstream LZ4 implementation is not under EROFS&#8217; control:<br \/>\nFor example, the literal copy memmove() may still **copy long literals<br \/>\nbackward** on x86 based on the address comparison even when the source<br \/>\nand destination ranges do not overlap (IOWs, inline decompression<br \/>\ndoesn&#8217;t need to be considered here). That breaks the rolling assumption<br \/>\nand makes the optimization broken.<\/p>\n<p>Disable it for now to make sure the data correctness first since EROFS<br \/>\nis used everywhere now: The rolling window approach can be revived once<br \/>\nwe either ensure that the official LZ4 code always copies forward for<br \/>\nnon-overlapping ranges or maintain our own LZ4 implementation in EROFS.<\/p>\n<p>The main impact is a higher runtime memory footprint; However, recent<br \/>\ncommit 0f6273ab4637 (&#8220;erofs: add a reserved buffer pool for lz4<br \/>\ndecompression&#8221;) helps mitigate this when enabled but it&#8217;s still not<br \/>\nperfect.<\/p>\n<p>[1] https:\/\/www.usenix.org\/conference\/atc19\/presentation\/gao<br \/>\n    \u00a7 3.3 Decompression<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>erofs: disable LZ4 rolling decompression for now<\/p>\n<p>LZ4 rolling decompression [1] was introduced to reduce the memory<br \/>\nfootprint of te<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-29222","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/29222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=29222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=29222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=29222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}