Embedded systems (the ones where you would disallow malloc) don't generally have virtual memory by virtue of having no MMU, so on those you can't do overcommitment since there is no page fault mechanism.

No, the reason is simply that by statically allocating all memory you can avoid entire classes of program faults and bugs. There are no memory leaks and you don't need to solve the NP-complete problem of "is there an execution path where a dynamic memory allocation will fail". Keep in mind that it is not just about the total amount of dynamically allocated memory, but also the order of allocations (and frees).

That's right - some "safe" coding standards like MISRA C go as far as forbidding use of malloc() without explicit justification.

If you still need dynamic allocation, you might choose to have a custom allocator working from a fixed-size pool or arena created in code (possibly itself carved out of RAM with malloc(), but importantly only once at first setup, where you have a better guarantee that the allocation will succeed).

I wouldn't say this is the reason. Embedded systems typically don't have virtual memory to start.

I would expect (but verify) a malloc implementation on embedded to return null if it can't satisfy the allocation.

But even with that assumption malloc in embedded is often a bad idea. You need to plan for worst case anyway and you can not afford memory fragmentation.

Aside from the fact that overcommit usually doesn't apply to embedded systems, malloc() is fine; its free() that is the problem.

I'd love to see how people design software with fully static memory (and limited one at that)