Re: Hrm, _that_ was easy. Fix for binfmt_elf coredump with funny mmap's , doing state D.

Greg Alexander (
Wed, 2 Apr 1997 11:16:45 -0500 (EST)

On Wed, 2 Apr 1997, John Carter wrote:

> > Here's my solution. I think it still dumps all that is needed in your
> > coredump, but if you have any probs don't use this. :)
> > - if (!(vma->vm_flags & (VM_READ|VM_WRITE|VM_EXEC)))
> > + if (!(vma->vm_flags & (VM_READ|VM_EXEC)))
> Yip. It works. Didn't quite patch clean to the version I had, but I
> did the patch by hand. But let me see if I understand this...
> If the proverbial hits the fan, the kernel says 'stopit!' and does a
> core dump. The coredump routine wombles through a list of vm areas
> associated with that process, and calls "maydump" to determine whether
> or not to write it out to the 'core' file. (Gives rise to rusty
> childhood memories of seeing little wires threaded through tiny iron
> rings, we really do drag the past with us...)
> What is the difference between VM_EXEC and VM_EXECUTABLE? My wild
> guess that one is an executable area of memory and the other is mapped
> to an executable file.

I have no idea. I just did what was necessary to make it not barf. I ran
some tests and it still seems to be dumping everything that's useful.

> Now From: David Schwartz <>
> > Do you get this bug even if you disable core dumps? I think it's an
> > ELF core-dump bug. If memory serves me, the ELF core-dump routine
> > tries to dump information from the mmap'ed file, but it's already
> > been unmapped because the process is dead.
> Hmm. If David is right, then my guess is this patch is the wrong fix,
> it may cease to dump info that may well be needed. The core dump
> should be done before the unmap'ing. Or the vma struct needs to
> somehow carry info to say that this vma was mmap'd, hence don't dump it.

You don't get it if you disable core dumps, that's correct. But a "dead"
process doesn't get it's mem unmapped before the ELF coredump is called.
mmap'd stuff is a rather important part of your dump. Everything you malloc
(with some libc's) is in an mmap. This whole list of things that is checked
by maydump (if I recall correctly) is in the mmap structure under
task_struct (i.e. p->mmap). And we definitely need to dump the stack,
there's no question about that.
I did some debugging and I found that for two different core dumps,
the only memory area not dumped that would have been dumped before was the
mmap'd area marked PROT_WRITE. It was causing an error before because
PROT_WRITE doesn't allow reading. I just made sure that it wouldn't let it
through if it had "read, execute, or write" but rather if it had "read or
execute" because write, by itself, is a guarantee of nothing.

Greg Alexander
Anyone who cannot cope with mathematics is not fully human. At best he is a
tolerable subhuman who has learned to wear shoes, bathe and not make messes
in the house.
-- Paul Erdos
also -- Lazarus Long, "Time Enough for Love"