Project

General

Profile

Actions

Bug #13927

closed

core dump of PROT_NONE segment leads to confusing behavior

Added by Robert Mustacchi 4 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

When working through #13925 I used mdb on a core file of a rust program and got the following unexpected behavior:

$ mdb core.dropshot.abrt 
mdb: core file data for mapping at fffffc7fed830000 not saved: Bad address
mdb: core file data for mapping at fffffc7fee760000 not saved: Bad address
mdb: core file data for mapping at fffffc7feed80000 not saved: Bad address
mdb: core file data for mapping at fffffc7feedb0000 not saved: Bad address
mdb: core file data for mapping at fffffc7feee00000 not saved: Bad address
mdb: core file data for mapping at fffffc7feee10000 not saved: Bad address
mdb: core file data for mapping at fffffc7feee30000 not saved: Bad address
mdb: core file data for mapping at fffffc7feee40000 not saved: Bad address
mdb: core file data for mapping at fffffc7feef10000 not saved: Bad address
mdb: core file data for mapping at fffffc7feef20000 not saved: Bad address
mdb: core file data for mapping at fffffc7feef30000 not saved: Bad address
mdb: core file data for mapping at fffffc7feef50000 not saved: Bad address
mdb: core file data for mapping at fffffc7feef70000 not saved: Bad address
mdb: core file data for mapping at fffffc7feef90000 not saved: Bad address
mdb: core file data for mapping at fffffc7feefa0000 not saved: Bad address
mdb: core file data for mapping at fffffc7feefc0000 not saved: Bad address
mdb: core file data for mapping at fffffc7feefd0000 not saved: Bad address
mdb: core file data for mapping at fffffc7feeff0000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef000000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef020000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef040000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef050000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef090000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef0a0000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef0c0000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef1b0000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef1c0000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef1e0000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef200000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef210000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef220000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef230000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef250000 not saved: Bad address
mdb: core file data for mapping at fffffc7fef2e0000 not saved: Bad address
Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ]

Notably, the same thing did not happen to the program when I loaded a core file taken via gcore of the same process before the abort. The first thing I did here was to look at the differences between the dumped regions. I did this by taking a pmap of both cores and the live process before these actions. If we look at one of the mappings of note:

$ pmap core.dropshot.abrt 
core 'core.dropshot.abrt' of 100621:    ./target/debug/examples/basic
...
FFFFFC7FED830000          4K -----*   [ anon ]
...

We have an asterisk here about failing to dump it and notably there are no protection flags specified. When I compared this to the live process and gcore, it was the same except without the asterisk indicating that we failed to dump. This is a region of PROT_NONE -- a guard page.

This is the program header from it via gcore:

Program Header[41]:
    p_vaddr:      0xfffffc7fed830000  p_flags:    0
    p_paddr:      0                   p_type:     [ PT_LOAD ]
    p_filesz:     0x1000              p_memsz:    0x1000
    p_offset:     0x17df37c           p_align:    0

And here is the corresponding header via the kernel:

Program Header[41]:
    p_vaddr:      0xfffffc7fed830000  p_flags:    [ PF_SUNW_FAILURE ]
    p_paddr:      0                   p_type:     [ PT_LOAD ]
    p_filesz:     0                   p_memsz:    0x1000
    p_offset:     0x17df37c           p_align:    0

Ultimately we should probably either write something sparse or note that this is PROT_NONE and not try to read it and have that fail.

Actions

Also available in: Atom PDF