I don't think a UAF on its own allows control hijacking in an exploit. You will need further logic bugs or the ability to legitimately or illegitimately control memory, either via further requests / function calls, OOB writes and such. And it will always be extremely specific to the application vulnerable.

For example, I remember an exploit workshop around reuse of passwd entries. The vulnerable would validate a passwd entry for a non-root user, use it a bit, and later on free and zero it out for security purposes... except it then looked at the passwd entry again in some conditions. Suddenly, the uid was non-zero at first, and zero later on, so later decisions assumed the user was root.

In a more concurrent situation, a possible vulnerability was a shared cache of these passwd entries. It wouldn't zero them out anymore, but you could create a race condition of starting requests as user A, and then hammering requests as user B, so you'd end up mixing up the permission contexts of these users. Because the passwd entry that had been released back to the pool was overwritten, and then re-read with the value from another context.

The necessary line of thinking tends to be very different from thinking about program code regularly.