CVE-2025-21664: dm thin: make get_first_thin use rcu-safe list first function
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.
Security readout for executives and security teams
Plain-English summary
A race in Linux device-mapper thin provisioning can make the kernel treat an emptied list as a live thin-volume object. A production kernel crash was reported, so affected storage hosts may suffer abrupt service interruption. CVSS 7.8 also indicates possible confidentiality and integrity impact, but the supplied evidence documents a crash, not proven data theft or malicious exploitation.
Executive priority
Treat this as a high-priority reliability and security update for critical systems that actually use device-mapper thin provisioning. The issue can crash the kernel and has a 7.8 CVSS score, but it requires local reachability and the supplied evidence does not support active exploitation.
Technical view
get_first_thin() performed separate RCU-unsafe list checks and retrievals. Concurrent thin-device teardown could remove the final active entry between reads, causing an invalid thin_c dereference in process_deferred_bios. The fix uses list_first_or_null_rcu(), which obtains a consistent result through one READ_ONCE()-based operation. Device-mapper delete and suspend tests reportedly found no regressions.
Likely exposure
Exposure is limited to Linux systems using device-mapper thin provisioning with an affected kernel or vendor backport. The CVSS vector indicates local access, low privileges, and no user interaction. Version strings alone may be insufficient because distributions and appliances can backport fixes; compare the running kernel against applicable vendor guidance.
Exploitation context
The CVE is not listed as KEV, and the supplied sources do not establish active malicious exploitation or a public exploit. They document a production crash caused by a concurrency race. This demonstrates real operational failure potential, but it is not evidence of attacker-driven exploitation.
Researcher notes
The race occurs when the final active thin is removed during teardown while deferred bios obtain the first thin. Reported artifacts included refcount saturation, a UBSAN out-of-bounds CPU access, queued-spinlock trouble, and a thread waiting in synchronize_rcu. These are useful diagnostic indicators, but their absence does not prove the kernel is unaffected.
Mitigation direction
Inventory Linux systems using device-mapper thin provisioning and identify their running kernel builds.
Apply the vendor-supported kernel update containing the relevant stable fix.
Reboot into the updated kernel and confirm the fixed build is running.
Prioritize affected storage hosts whose failure would interrupt critical services.
Validation and detection
Compare running kernel builds with applicable distribution or appliance advisories.
Confirm the relevant fix or vendor backport appears in package changelogs or kernel source.
Run vendor-approved thin-provisioning delete and suspend regression tests in staging.
Review kernel logs for refcount saturation, UBSAN errors, queued-spinlock errors, or general-protection faults.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-21664 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
2ADP providers
11Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.