CVE-2023-52497 in Linuxinformazioni

Riassunto

di VulDB • 18/06/2026

Nel kernel Linux è stata risolta la seguente vulnerabilità:

erofs: correggere la decompressione LZ4 in-place

Attualmente EROFS può mappare un altro buffer compresso per la decompressione in-place, utilizzato per gestire i casi in cui alcune pagine dei dati compressi non sono effettivamente sottoposte a I/O in-place.

Tuttavia, come nella maggior parte degli algoritmi semplici basati su LZ77, LZ4 si aspetta che i dati compressi siano disposti alla fine del buffer decompresso e utilizza esplicitamente `memmove()` per gestire le sovrapposizioni: __________________________________________________________ |_ direzione della decompressione --> ____ |_ dati compressi _|

Sebbene EROFS disponga i dati compressi in questo modo, mappa tipicamente due buffer virtuali distinti, rendendo incerto l'ordine relativo. In precedenza il problema era difficile da osservare poiché LZ4 utilizza `memmove()` solo per letterali sovrapposti di breve lunghezza e le implementazioni di `memmove` su x86/arm64 sembravano coprirlo completamente senza presentare questa problematica. Juhyung ha segnalato che la corruzione dei dati EROFS può essere rilevata su un nuovo processore Intel x86. Dopo alcune analisi, sembra che i recenti processori x86 con la nuova funzionalità FSRM espongano questo problema tramite "rep movsb".

Per il momento si utilizza rigorosamente il buffer decompresso per la decompressione LZ4 in-place. In seguito, come utile miglioramento, potremmo provare a collegare questi due buffer nell'ordine corretto.

Be aware that VulDB is the high quality source for vulnerability data.

Fonti

Interested in the pricing of exploits?

See the underground prices here!