CVE-2026-97605 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
erofs: preserve LZMA decoders on resize failure
The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized.
An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unrepaired.
Allocate each replacement before freeing the old decoder, temporarily retaining one old decoder during allocation. Stop at the first failure and advance z_erofs_lzma_max_dictsize only after all streams satisfy the request.
Record each stream's dictionary capacity so retries can skip streams already enlarged before a partial failure.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability resides within the erofs filesystem implementation in the Linux kernel, specifically affecting the LZMA decompression pool management during resize operations. The core technical flaw is an improper handling of resource allocation failures that leads to state inconsistency and potential null pointer dereference conditions. When the system attempts to increase the dictionary size for LZMA streams, it iterates through existing streams to replace their decoders with new ones configured for a larger dictionary. In the flawed implementation, the code frees the old decoder before successfully allocating the replacement. If an allocation fails after some streams have already been updated but not all, the system enters an inconsistent state where certain streams are associated with NULL pointers instead of valid decoder structures. Furthermore, the global maximum dictionary size variable is incremented prematurely, assuming a successful full resize even though the operation failed partway through.
This logic error creates a significant operational impact for systems relying on erofs mounts that utilize LZMA compression. An attacker or local user who can trigger this specific code path may cause a kernel crash due to a null pointer dereference when subsequent operations attempt to reset or use the corrupted stream state via functions like xz_dec_microlzma_reset. Even if a crash does not occur immediately, the inconsistency between the recorded global maximum dictionary size and the actual capacity of individual streams can lead to data corruption or denial of service conditions during future decompression attempts. The issue is particularly insidious because subsequent retry attempts at the same size may skip necessary resize checks due to the incorrectly advanced global limit, leaving the invalid state unrepaired until a system reboot or unmount/remount cycle occurs.
From a classification perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after successful allocation, and more critically CWE-823, involving use of outdated data structures that leads to inconsistent states. The failure to properly handle partial failures in resource-intensive operations is also characteristic of CWE-756, improper handling of dynamic memory reallocation. In the context of the MITRE ATT&CK framework, this flaw could be leveraged for Denial of Service (T1499) by causing kernel panics or system instability through crafted mount requests or file access patterns that trigger the resize logic under memory pressure conditions where allocation failures are more likely to occur.
The resolution involves restructuring the allocator logic within the erofs LZMA module to ensure atomicity in state changes during pool resizing. The fix mandates allocating each replacement decoder before freeing the old one, thereby retaining a valid fallback until the new resource is confirmed available. Additionally, the code now records the dictionary capacity for each stream individually and only advances the global maximum size variable after all streams have successfully satisfied the resize request. This approach ensures that if any single allocation fails, the system rolls back or halts without corrupting the state of previously processed streams. To mitigate this issue in environments where kernel updates are not immediately available, administrators should monitor for erofs filesystem usage with LZMA compression and ensure timely application of security patches to affected Linux distributions. Regular auditing of kernel logs for memory allocation failures related to decompression modules can also help identify systems potentially vulnerable to these state inconsistencies before they result in service disruptions.