And that is the main risk here, as was clearly laid out in the advisory. The main reason why this is big is not that you can do that much to the system, it is the sheer amount of stuff that is affected.

As for a more useful exploit, well a double free causes corruption of memory somewhere. With more traditional means of doing so (eg buffer overflows) you get some control over what is corrupted, where. With a double free you don't. It is theoretically possible that the corruption could be such that you won't core dump, but instead will do something random. For instance a double-free at point A will lead to point B starting to execute code from point C, where C holds a user-defined text string. In that event then, given the fact that memory allocation issues are often deterministic, you might get the ability to exploit an application.

The possibility is admittedly remote, and would take both luck and careful analysis to find. But full exploits have been demonstrated in the past of this type of bug, and it is likely that between all of the architectures and applications that there are a few exploitable instances out there.

As is normal when talking about security and bugs, identifying which ones are exploitable is not really worth it (unless you are a black hat). The bug exists, is fixable, and fixing it is easier than detailed analysis.

Cheers,
Ben