cbcvebase.
CVE-2025-21664
published 2025-01-21

CVE-2025-21664: 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…

PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.23%
14.0th percentile
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.

Affected

35 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.128-1 (bookworm)linux 6.1.128-1 (bookworm)
debianlinux-6.1< linux 6.1.128-1 (bookworm)linux 6.1.128-1 (bookworm)
linuxlinux
linuxlinux>= b10ebd34cccae1b431caf1be54919aede2be7cbe < ec037fe8c0d0f6140e3d8a49c7b29cb5582160b8ec037fe8c0d0f6140e3d8a49c7b29cb5582160b8
linuxlinux>= b10ebd34cccae1b431caf1be54919aede2be7cbe < cd30a3960433ec2db94b3689752fa3c5df44d649cd30a3960433ec2db94b3689752fa3c5df44d649
linuxlinux>= b10ebd34cccae1b431caf1be54919aede2be7cbe < 802666a40c71a23542c43a3f87e3a2d0f4e8fe45802666a40c71a23542c43a3f87e3a2d0f4e8fe45
linuxlinux>= b10ebd34cccae1b431caf1be54919aede2be7cbe < 12771050b6d059eea096993bf2001da9da9fddff12771050b6d059eea096993bf2001da9da9fddff
linuxlinux>= b10ebd34cccae1b431caf1be54919aede2be7cbe < 6b305e98de0d225ccebfb225730a9f560d28ecb06b305e98de0d225ccebfb225730a9f560d28ecb0
linuxlinux>= b10ebd34cccae1b431caf1be54919aede2be7cbe < cbd0d5ecfa390ac29c5380200147d09c381b2ac6cbd0d5ecfa390ac29c5380200147d09c381b2ac6
linuxlinux>= b10ebd34cccae1b431caf1be54919aede2be7cbe < 80f130bfad1dab93b95683fc39b87235682b8f7280f130bfad1dab93b95683fc39b87235682b8f72
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 5.10.234-15.10.234-1
linuxlinux_kernel>= 0 < 6.1.128-16.1.128-1
linuxlinux_kernel>= 0 < 6.12.10-16.12.10-1

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.8HIGH
vendor_ubuntu7.8HIGH
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.