In the Linux kernel, the following vulnerability has been resolved:
dm thin: make getfirstthin use rcu-safe list first function
The documentation in rculist.h explains the absence of listemptyrcu() and cautions programmers against relying on a listempty() -> listfirst() sequence in RCU safe code. This is because each of these functions performs its own READONCE() of the list head. This can lead to a situation where the listempty() 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 processdeferredbios path. This function saw a valid list head in getfirstthin() but when it subsequently dereferenced that and turned it into a thinc, 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 refcountt 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 thindtr's synchronizercu.
The thindtr call managed to pull the thinc 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 getfirstthin() function to use listfirstornullrcu() 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.