Good bit of background on this one, does a good job of explaining the root of the issue. There are two parts, first is a 2020 CVE. Within DirectComposition you can create Tracker objects, and TrackerBindingManager which will manage pairs of trackers. The trackers in-turn when a binding is added will store a pointer to its BindingManager. When you free one tracker, it’ll free the other, and of course it’ll free its entry in the BindingManager’s list. It does this by setting the list’s entry->entry_id to 0, then another function iterates and removes the zeroed entries. Vulnerability being that while tracker’s only maintain a reference to one manager, you can add it to multiple managers. When free’d only the one binding manager will be freed, leaving a dangling pointer in the older managers. The object has a function pointer that is called on Commit so rip control is possible with a UAF

The patch for this is that it would check if the tracker->binding_obj is zero before adding it. If it is already bound then it won’t add the binding. The bypass is to take advantage of the fact that an entry->id==0 is a special case internally. You can update the binding manager and provide a new entry id for a tracker pair, setting that to 0 will trigger a call to have the BindingManagerReferences removed, but not a call to free the trackers. Enabling you to zero the binding_obj and access the original vulnerability.