CVE-2025-21664

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm thin: make get_first_thin use rcu-safe list first function<br /> <br /> The documentation in rculist.h explains the absence of list_empty_rcu()<br /> and cautions programmers against relying on a list_empty() -&gt;<br /> list_first() sequence in RCU safe code. This is because each of these<br /> functions performs its own READ_ONCE() of the list head. This can lead<br /> to a situation where the list_empty() sees a valid list entry, but the<br /> subsequent list_first() sees a different view of list head state after a<br /> modification.<br /> <br /> In the case of dm-thin, this author had a production box crash from a GP<br /> fault in the process_deferred_bios path. This function saw a valid list<br /> head in get_first_thin() but when it subsequently dereferenced that and<br /> turned it into a thin_c, it got the inside of the struct pool, since the<br /> list was now empty and referring to itself. The kernel on which this<br /> occurred printed both a warning about a refcount_t being saturated, and<br /> a UBSAN error for an out-of-bounds cpuid access in the queued spinlock,<br /> prior to the fault itself. When the resulting kdump was examined, it<br /> was possible to see another thread patiently waiting in thin_dtr&amp;#39;s<br /> synchronize_rcu.<br /> <br /> The thin_dtr call managed to pull the thin_c out of the active thins<br /> list (and have it be the last entry in the active_thins list) at just<br /> the wrong moment which lead to this crash.<br /> <br /> Fortunately, the fix here is straight forward. Switch get_first_thin()<br /> function to use list_first_or_null_rcu() which performs just a single<br /> READ_ONCE() and returns NULL if the list is already empty.<br /> <br /> This was run against the devicemapper test suite&amp;#39;s thin-provisioning<br /> suites for delete and suspend and no regressions were observed.