[Bug dynamic-link/22370] Incorrect note padding check

cvs-commit at gcc dot gnu.org sourceware-bugzilla@sourceware.org
Tue Nov 28 17:57:00 GMT 2017


https://sourceware.org/bugzilla/show_bug.cgi?id=22370

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  8d81ce0c6d6ca923571e8b2bac132929f9a02973 (commit)
      from  313ba4630f5f891af22bea9bdf9d9f3c88e49aee (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8d81ce0c6d6ca923571e8b2bac132929f9a02973

commit 8d81ce0c6d6ca923571e8b2bac132929f9a02973
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Nov 28 09:56:47 2017 -0800

    Properly compute offsets of note descriptor and next note [BZ #22370]

    A note header has 3 4-bytes fields, followed by note name and note
    descriptor.  According to gABI, in a note entry, the note name field,
    not note name size, is padded for the note descriptor.  And the note
    descriptor field, not note descriptor size, is padded for the next
    note entry.  Notes are aligned to 4 bytes in 32-bit objects and 8 bytes
    in 64-bit objects.

    For all GNU notes, the name is "GNU" which is 4 bytes.  They have the
    same format in the first 16 bytes in both 32-bit and 64-bit objects.
    They differ by note descriptor size and note type.  So far, .note.ABI-tag
    and .note.gnu.build-id notes are always aligned to 4 bytes.  The exsting
    codes compute the note size by aligning the note name size and note
    descriptor size to 4 bytes.  It happens to produce the same value as
    the actual note size by luck since the name size is 4 and offset of the
    note descriptor is 16.  But it will produce the wrong size when note
    alignment is 8 bytes in 64-bit objects.

    This patch defines ELF_NOTE_DESC_OFFSET and ELF_NOTE_NEXT_OFFSET to
    properly compute offsets of note descriptor and next note.  It uses
    alignment of PT_NOTE segment to support both 4-byte and 8-byte note
    alignments in 64-bit objects.  To handle PT_NOTE segments with
    incorrect alignment, which may lead to an infinite loop, if segment
    alignment is less than 4, we treate alignment as 4 bytes since some
    note segments have 0 or 1 byte alignment.

        [BZ #22370]
        * elf/dl-hwcaps.c (ROUND): Removed.
        (_dl_important_hwcaps): Replace ROUND with ELF_NOTE_DESC_OFFSET
        and ELF_NOTE_NEXT_OFFSET.
        * elf/dl-load.c (ROUND): Removed.
        (open_verify): Replace ROUND with ELF_NOTE_NEXT_OFFSET.
        * elf/readelflib.c (ROUND): Removed.
        (process_elf_file): Replace ROUND with ELF_NOTE_NEXT_OFFSET.
        * include/elf.h [!_ISOMAC]: Include <libc-pointer-arith.h>.
        [!_ISOMAC] (ELF_NOTE_DESC_OFFSET): New.
        [!_ISOMAC] (ELF_NOTE_NEXT_OFFSET): Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog        |   14 ++++++++++++++
 elf/dl-hwcaps.c  |   24 ++++++++++++++++++------
 elf/dl-load.c    |   19 +++++++++++++++----
 elf/readelflib.c |   19 +++++++++++++++----
 include/elf.h    |   16 ++++++++++++++--
 5 files changed, 76 insertions(+), 16 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list