[0/4] bfd: Add support for Cygwin x86_64 core dumps

Message ID 20200703140505.26682-1-jon.turney@dronecode.org.uk
Headers show
Series
  • bfd: Add support for Cygwin x86_64 core dumps
Related show

Message

Jon Turney July 3, 2020, 2:05 p.m.
Fixes and additions support x86_64 in reading the NT_WIN32PSTATUS ELF notes
in a Cygwin "core dump".

As far as I know, the only way to generate these "core dumps" is to use
Cygwin's 'dumper' tool, which requires some fixes on x86_64 [1].

[1] https://cygwin.com/pipermail/cygwin-patches/2020q3/010313.html

Jon Turney (4):
  Read tid from correct offset in win32pstatus NOTE_INFO_THREAD
  Don't apply size constraint to all win32pstatus ELF notes.
  Don't hardcode CONTEXT size for a NOTE_INFO_THREAD win32pstatus note
  Add handling for 64-bit module addresses in Cygwin core dumps

 bfd/ChangeLog | 21 +++++++++++++++++++++
 bfd/elf.c     | 29 ++++++++++++++++++-----------
 2 files changed, 39 insertions(+), 11 deletions(-)

-- 
2.27.0

Comments

Jan Beulich via Binutils July 9, 2020, 1:38 p.m. | #1
Hi Jon,

> Fixes and additions support x86_64 in reading the NT_WIN32PSTATUS ELF notes

> in a Cygwin "core dump".


The patch series looks fine to me apart from one thing:

From patch 2/4:

  -  if (note->descsz < 728)
  -    return TRUE;

Without this check it will be possible for a corrupt core file
to trigger invalid reads beyond the end of the note section.
(Binary fuzzers love triggering this kind of bug).  So I think
that everywhere you read data from a note you should make sure
that there actually is data present first.

Cheers
  Nick
Jon Turney July 12, 2020, 12:57 p.m. | #2
On 09/07/2020 14:38, Nick Clifton via Binutils wrote:
> Hi Jon,

> 

>> Fixes and additions support x86_64 in reading the NT_WIN32PSTATUS ELF notes

>> in a Cygwin "core dump".

> 

> The patch series looks fine to me apart from one thing:

> 

>  From patch 2/4:

> 

>    -  if (note->descsz < 728)

>    -    return TRUE;

> 

> Without this check it will be possible for a corrupt core file

> to trigger invalid reads beyond the end of the note section.

> (Binary fuzzers love triggering this kind of bug).  So I think

> that everywhere you read data from a note you should make sure

> that there actually is data present first.


Yes, that should be done.  I posted a revised patch set with that added.