Back

HIGH

shmem: fix recovery on rename failures

Published Jan 13, 2026

Description

maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange().

Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout().

Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton.

For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations.

For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations.

That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout().

Affected products

Remediation

Red Hat statement

Triggering this vulnerability requires extreme memory exhaustion conditions during tmpfs rename operations. Normal system operation with adequate memory is unaffected. The filesystem inconsistency could cause subsequent directory operations to fail unexpectedly.

Metrics

Weaknesses (1)

References (8)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner Linux
Published Jan 13, 2026
Updated Aug 5, 2026
Reserved Jan 13, 2026
NVD
Status Modified
Modified Jul 30, 2026
Red Hat
Severity Low
Public date Jan 13, 2026