CVE-2023-52497

What it actually does

EROFS LZ4 inplace decompression maps separate virtual buffers whose relative ordering is not guaranteed, allowing memmove() during overlapping literal copies to produce incorrect results on x86 CPUs with the FSRM "rep movsb" implementation and resulting in data corruption inside the decompressed buffer.

Why it matters to the business

Systems using EROFS with LZ4 compression on recent Intel processors may silently corrupt file data, causing application failures, filesystem inconsistencies, or loss of integrity for any workloads that read compressed EROFS images.

How an attack unfolds

An attacker with the ability to supply or influence EROFS filesystem images triggers decompression of specially arranged compressed data that relies on overlapping literals; on vulnerable hardware the uncertain buffer ordering combined with the new memmove implementation produces corrupted output that can be observed or leveraged for further impact.

How to fix it

Upgrade the Linux kernel to a version containing commit 9ff2d260b25df6fe1341a79113d88fecf6bd553e or later; rebuild and redeploy any custom kernels or distributions that include the affected EROFS code; test LZ4-compressed EROFS workloads on the patched kernel before wide deployment.

How to confirm the fix worked

Confirm the running kernel contains commit 9ff2d260b25df6fe1341a79113d88fecf6bd553e; exercise EROFS LZ4 decompression with known overlapping-literal test images and verify that no data corruption occurs; monitor for EROFS read errors or checksum mismatches on patched systems.

Typical attack path

1. Obtain or create an EROFS image containing LZ4-compressed data with short overlapping literals
2. Mount the image on a vulnerable kernel running on a recent Intel x86 CPU with FSRM enabled
3. Trigger reads that exercise the inplace decompression path
4. Observe or exploit the resulting data corruption

How to detect it

Search kernel logs for EROFS read or decompression errors, unexpected data checksum failures, or corruption reports on systems with recent Intel CPUs; examine any crash dumps or application-level integrity failures that coincide with EROFS mounts.

What your security team should do

• Prioritize kernel upgrades on any systems that mount EROFS volumes with LZ4 compression
• Add the fixed commit identifier to internal kernel build and patch-management processes
• Restrict untrusted EROFS images until patches are applied
• Include EROFS decompression paths in regression test suites for new Intel hardware