Does malloc without corresponding free always produce a memory leak, or are there situations when it doesn't?
It depends on how you define "memory leak". If you define it as having any outstanding objects with allocated storage duration at the time of program exit, then yes, it's a leak. This is what tools like valgrind report. However, it's not a useful definition at all.
My definition of memory leak is roughly an unbounded increase in total memory consumption of the program over its lifetime despite having a bounded working set. For example, if I always have at most 10 tabs open in my browser, to the same 10 sites, but memory usage keeps increasing unboundedly, that's a memory leak. On the other hand, a program that allocates a buffer to load a whole file into memory, loads the file, prints it in reverse, then exits without freeing the memory does not have a memory leak.
One particular important case where a malloc without free is not only not-a-leak but absolutely necessary (for general code that can't make assumptions about the whole program it's running in) is any use of runtime-allocated constant tables whose generation is controlled by call_once. No matter how late you tried to free such tables, it would be possible for code (in another thread, or an atexit handler, etc.) to attempt to access it after free, and call_once type interfaces intentionally do not provide any way to synchronize any access except first call (this is how they avoid introducing unwanted acquire barriers/synchronization cost at every read).
Note that the concept of "working set" here is somewhat subjective and highly load-bearing. Often memory leaks are a matter of the software still considering something part of its working set when the user no longer considers it so.