CVE-2025-21664 Affecting kernel-cross-headers package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL8-KERNELCROSSHEADERS-8669936
- published29 Jan 2025
- disclosed21 Jan 2025
Introduced: 21 Jan 2025
NewCVE-2025-21664 (opens in a new tab)How to fix?
There is no fixed version for RHEL:8 kernel-cross-headers.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-cross-headers package and not the kernel-cross-headers package as distributed by RHEL.
See How to fix? for RHEL:8 relevant fixed versions and status.
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.
References
- https://access.redhat.com/security/cve/CVE-2025-21664
- https://git.kernel.org/stable/c/12771050b6d059eea096993bf2001da9da9fddff
- https://git.kernel.org/stable/c/6b305e98de0d225ccebfb225730a9f560d28ecb0
- https://git.kernel.org/stable/c/80f130bfad1dab93b95683fc39b87235682b8f72
- https://git.kernel.org/stable/c/cbd0d5ecfa390ac29c5380200147d09c381b2ac6
- https://git.kernel.org/stable/c/802666a40c71a23542c43a3f87e3a2d0f4e8fe45