coredump: Don't assume that the number of ELF segments is consistent

[markj]

Summary

In an ELF coredump, each dumped vm_map_entry is represented by a
segment. __elfN(coredump) first computes the number of segments by
looping over the vm_map entries (in each_dumpable_segment()), then
allocates a buffer to hold the ELF header and program headers, then
loops over the entries again to populate the program headers.

each_dumpable_segment() holds the vm_map read lock, but that lock is
dropped between the two calls. If the map is shared with another
process, via rfork(), then the map can change. cb_put_phdr() did not
account for this, and so could write out of bounds.

Add a check to prevent this; simply do not write out excess segments.

Reported by: Maik Muench of Secfault Security

[markj]

sys/kern/imgact_elf.c

1713

This M_ZERO is to make sure we don't write out uninitialized memory if the number of phdrs shrinks instead of growing.

In general, if something is mutating the vm_map as we're writing out a core dump, then I don't expect the core dump to be consistent; it's enough to ensure that such races don't trigger any memory safety problems in the kernel.

[kib]

sys/kern/imgact_elf.c

1713

I would put the text into the comment in the code.

[markj]

Review feedback.