How do I use thread-specific storage safely?

It seems to me you are focusing on thread-local storage unnecessarily for this type of discussion. Let's revisit your example:

buffer.data = 1;
2 = buffer.data;
buffertss.3 = buffertss;
tssset(buffertss.3, 2);

globalptr = malloc(10);

What happens in this thread terminates right after malloc executes? Memory leak happens. Ditto for realloc, except in realloc case you might also get use-after-free...

See, if you consider sudden thread death then you've got much bigger problems than threadlocal memory leaks. Generally speaking, if you consider sudden thread death as a possible event then you can't do that much safely. I mean, sudden thread death is definitely an UB, but it is also highly problematic from practical standpoint.

• thread exit by returning from thread entry proc
• thread exit by calling thrdexit
• thread exit by cancelling cancellable thread at one of the cancellation points (in pthreads case) - probably an UB?

In any of these cases, you know places thread might possible cease to exist so you could account for that by ensuring there are no lingering local pointer ownership through those points. Particularly, this:

tssset(buffertss, buffer.data = realloc(buffer.data, buffer.capacity * sizeof(char)));

can only be terminated by a sudden thread death (in which case tss destructors probably won't run anyway so ALL of the thread-local memory gets lost anyway).

A thread only terminates when it wants to. If we're talking C11 threads, there is simply no way to make a thread other than the current thread terminate. There is no C library function to cause that. If we're talking pthreads, you can send a cancellation request to a thread, but the thread can pop and call its cancellation handler. Then again, by default the cancellation will only happen at well-defined cancellation points, which your code fragment does not have. On Windows, there's TerminateThread, but the documentation warns you that this function is dangerous and you should not call it unless you know exactly what the other thread is doing and can guarantee it is safe.

So the short answer is that the thread simply won't terminate at those lines.

What happens if the thread terminates between lines 4 and 8 ?

If a thread terminates at a point that you did not or could not plan for, then your program likely breaks. Implications depend on what work your program does. Sure, you might end up with a memory leak, but that's pretty benign compared to some of the alternatives. Worrying about poor interactions with TSS in particular is missing the forest because of the trees. In fact, it's missing the forest because of a tiny little sapling, for your implementation's thread library is the single most likely place to be hardened against interesting thread behaviors.

What's more, You've expressed the question in terms of the C11 thread functions. C11 does not define any way for a thread without to terminate other than by its own initiative, except for the whole program to terminate. Thus, if a thread terminates at the point in question, but the rest of the program continues, then C doesn't have anything to say about what happens. You're already into UB as far as C is concerned. And for the case where the whole program terminates, the question is not meaningfully different from that of what happens when a single-threaded program terminates without freeing all dynamically allocated memory. (For most hosted C implementations, that has no averse effects.)

On the other hand, several popular threading implementations do in fact support thread cancellation by other threads. Among those with C APIs, both pthreads and Windows threads do, though for pthreads, it is a per-thread option, disabled by default. Using such cancellation features is widely considered unsafe, carrying a risk of resource corruption, but this is an easy problem to avoid: don't do that. Don't use such features in your own code, and avoid third-party libraries that do. And again, if you did end up with such a thread cancelation, then its effect on TSS is the least of your worries.

I generally go even farther. Pthreads is the threading implementation I ordinarily work with, and it tries very hard to provide a viable thread cancellation model with its default "deferred" cancellation type. Your particular question is moot for this form of cancellation, as pthreads is in control of the places where thread cancellation can take effect. Pthreads also provides for registering cleanup handlers by which user code can provide for resource cleanup upon thread cancellation. Even with those features, my blanket recommendation is still don't do it. Thread cancellation is bad news. If your code does not do any thread cancellations itself, then any that happen anyway are impossible to reason about. Focus on the things you can actually do something about.