ghsa-vp4f-mc7f-v3pc
Vulnerability from github
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": [],
"aliases": [
"CVE-2025-21664"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T13:15:10Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: make get_first_thin use rcu-safe list first function\n\nThe documentation in rculist.h explains the absence of list_empty_rcu()\nand cautions programmers against relying on a list_empty() -\u003e\nlist_first() sequence in RCU safe code. This is because each of these\nfunctions performs its own READ_ONCE() of the list head. This can lead\nto a situation where the list_empty() sees a valid list entry, but the\nsubsequent list_first() sees a different view of list head state after a\nmodification.\n\nIn the case of dm-thin, this author had a production box crash from a GP\nfault in the process_deferred_bios path. This function saw a valid list\nhead in get_first_thin() but when it subsequently dereferenced that and\nturned it into a thin_c, it got the inside of the struct pool, since the\nlist was now empty and referring to itself. The kernel on which this\noccurred printed both a warning about a refcount_t being saturated, and\na UBSAN error for an out-of-bounds cpuid access in the queued spinlock,\nprior to the fault itself. When the resulting kdump was examined, it\nwas possible to see another thread patiently waiting in thin_dtr\u0027s\nsynchronize_rcu.\n\nThe thin_dtr call managed to pull the thin_c out of the active thins\nlist (and have it be the last entry in the active_thins list) at just\nthe wrong moment which lead to this crash.\n\nFortunately, the fix here is straight forward. Switch get_first_thin()\nfunction to use list_first_or_null_rcu() which performs just a single\nREAD_ONCE() and returns NULL if the list is already empty.\n\nThis was run against the devicemapper test suite\u0027s thin-provisioning\nsuites for delete and suspend and no regressions were observed.",
"id": "GHSA-vp4f-mc7f-v3pc",
"modified": "2025-02-02T12:30:25Z",
"published": "2025-01-21T15:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21664"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12771050b6d059eea096993bf2001da9da9fddff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b305e98de0d225ccebfb225730a9f560d28ecb0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/802666a40c71a23542c43a3f87e3a2d0f4e8fe45"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80f130bfad1dab93b95683fc39b87235682b8f72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cbd0d5ecfa390ac29c5380200147d09c381b2ac6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd30a3960433ec2db94b3689752fa3c5df44d649"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec037fe8c0d0f6140e3d8a49c7b29cb5582160b8"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.