CVE-2025-21664: dm thin: make get_first_thin use rcu-safe list first function
First published: Tue Jan 21 2025(Updated: )
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.
Credit: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
| Affected Software | Affected Version | How to fix |
|---|---|---|
| Linux Kernel |
Never miss a vulnerability like this again
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
Reference Links
- https://git.kernel.org/stable/c/ec037fe8c0d0f6140e3d8a49c7b29cb5582160b8
- https://git.kernel.org/stable/c/cd30a3960433ec2db94b3689752fa3c5df44d649
- https://git.kernel.org/stable/c/802666a40c71a23542c43a3f87e3a2d0f4e8fe45
- 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
Frequently Asked Questions
What is the severity of CVE-2025-21664?
CVE-2025-21664 is classified as a moderate severity vulnerability in the Linux kernel.
How do I fix CVE-2025-21664?
To fix CVE-2025-21664, update the Linux kernel to the latest version that contains the security patch.
What components of the Linux kernel are affected by CVE-2025-21664?
CVE-2025-21664 affects the dm thin component of the Linux kernel.
Is CVE-2025-21664 being exploited in the wild?
As of now, there have been no confirmed reports of CVE-2025-21664 being actively exploited in the wild.
Where can I find more information about CVE-2025-21664?
Detailed technical information about CVE-2025-21664 can be found in the Linux kernel's commit history.
- agent/title
- agent/first-publish-date
- agent/description
- agent/type
- agent/author
- agent/event
- agent/source
- agent/last-modified-date
- agent/references
- collector/epss-latest
- source/FIRST
- agent/epss
- agent/softwarecombine
- agent/tags
- agent/guess-ai
- agent/software-canonical-lookup
- agent/software-canonical-lookup-request
- collector/mitre-cve
- source/MITRE
- collector/nvd-api
- source/NVD
- vendor/linux
- canonical/linux kernel