Earlier quoted context omitted.
MS-DOS doesn’t have memory protection, so another option is that the running program[1] or something like a TSR or driver could have corrupted the headers. [1] I guess in a modern system a process can still trash its own malloc, but not the kernel’s page allocation data.
Oh sure, and that happened a lot, but you'd usually see a gp fault before you would anything obscure...
I should also note this error is the return code for MS-DOS’s memory management functions (such as int 21h ax 48h / 49h), vaguely similar to malloc() returning NULL. It’s not a fatal error, so how it’s handled depends on the programme. It could bail out, perhaps with a more general “out of memory” error, or try and carry on, or perhaps just start overwriting parts of the interrupt vector table as that’s where segment 0007h would start at…
(Though in the latter case on DOS just blindly assuming a memory allocation worked would be rather unwise so you’d hope just about everything checks the carry flag first).