linux-cve-announce - CVE-2025-71072: shmem: fix recovery on rename failures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2026011325-CVE-2025-71072-b52b@gregkh>
Date: Tue, 13 Jan 2026 16:31:30 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-71072: shmem: fix recovery on rename failures

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

shmem: fix recovery on rename failures

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().

The Linux kernel CVE team has assigned CVE-2025-71072 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 6.6 with commit a2e459555c5f9da3e619b7e47a63f98574dc75f1 and fixed in 6.12.64 with commit 4b0fe71fb3965d0db83cdfc2f4fe0b3227d70113
	Issue introduced in 6.6 with commit a2e459555c5f9da3e619b7e47a63f98574dc75f1 and fixed in 6.18.3 with commit 4642686699a46718d7f2fb5acd1e9d866a9d9cca
	Issue introduced in 6.6 with commit a2e459555c5f9da3e619b7e47a63f98574dc75f1 and fixed in 6.19-rc2 with commit e1b4c6a58304fd490124cc2b454d80edc786665c

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-71072
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	fs/libfs.c
	include/linux/fs.h
	mm/shmem.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/4b0fe71fb3965d0db83cdfc2f4fe0b3227d70113
	https://git.kernel.org/stable/c/4642686699a46718d7f2fb5acd1e9d866a9d9cca
	https://git.kernel.org/stable/c/e1b4c6a58304fd490124cc2b454d80edc786665c