linux-cve-announce - CVE-2025-21664: dm thin: make get_first

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: <2025012135-CVE-2025-21664-3744@gregkh>
Date: Tue, 21 Jan 2025 13:18:43 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2025-21664: dm thin: make get_first_thin use rcu-safe list first function

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

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

dm thin: make get_first_thin use rcu-safe list first function

The documentation in rculist.h explains the absence of list_empty_rcu()
and cautions programmers against relying on a list_empty() ->
list_first() sequence in RCU safe code.  This is because each of these
functions performs its own READ_ONCE() of the list head.  This can lead
to a situation where the list_empty() sees a valid list entry, but the
subsequent list_first() sees a different view of list head state after a
modification.

In the case of dm-thin, this author had a production box crash from a GP
fault in the process_deferred_bios path.  This function saw a valid list
head in get_first_thin() but when it subsequently dereferenced that and
turned it into a thin_c, it got the inside of the struct pool, since the
list was now empty and referring to itself.  The kernel on which this
occurred printed both a warning about a refcount_t being saturated, and
a UBSAN error for an out-of-bounds cpuid access in the queued spinlock,
prior to the fault itself.  When the resulting kdump was examined, it
was possible to see another thread patiently waiting in thin_dtr's
synchronize_rcu.

The thin_dtr call managed to pull the thin_c out of the active thins
list (and have it be the last entry in the active_thins list) at just
the wrong moment which lead to this crash.

Fortunately, the fix here is straight forward.  Switch get_first_thin()
function to use list_first_or_null_rcu() which performs just a single
READ_ONCE() and returns NULL if the list is already empty.

This was run against the devicemapper test suite's thin-provisioning
suites for delete and suspend and no regressions were observed.

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

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

	Issue introduced in 3.15 with commit b10ebd34cccae1b431caf1be54919aede2be7cbe and fixed in 6.1.125 with commit 12771050b6d059eea096993bf2001da9da9fddff
	Issue introduced in 3.15 with commit b10ebd34cccae1b431caf1be54919aede2be7cbe and fixed in 6.6.72 with commit 6b305e98de0d225ccebfb225730a9f560d28ecb0
	Issue introduced in 3.15 with commit b10ebd34cccae1b431caf1be54919aede2be7cbe and fixed in 6.12.10 with commit cbd0d5ecfa390ac29c5380200147d09c381b2ac6
	Issue introduced in 3.15 with commit b10ebd34cccae1b431caf1be54919aede2be7cbe and fixed in 6.13 with commit 80f130bfad1dab93b95683fc39b87235682b8f72

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-21664
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:
	drivers/md/dm-thin.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/12771050b6d059eea096993bf2001da9da9fddff
	https://git.kernel.org/stable/c/6b305e98de0d225ccebfb225730a9f560d28ecb0
	https://git.kernel.org/stable/c/cbd0d5ecfa390ac29c5380200147d09c381b2ac6
	https://git.kernel.org/stable/c/80f130bfad1dab93b95683fc39b87235682b8f72