[Bug binutils/22444] New: Incorrect note padding check

[hjl.tools at gmail dot com]

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

            Bug ID: 22444
           Summary: Incorrect note padding check
           Product: binutils
           Version: 2.30 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

readelf.c has

          inote.type     = BYTE_GET (external->type);
          inote.namesz   = BYTE_GET (external->namesz);
          inote.namedata = external->name;
          inote.descsz   = BYTE_GET (external->descsz);
          inote.descdata = inote.namedata + align_power (inote.namesz, 2);
          inote.descpos  = offset + (inote.descdata - (char *) pnotes);
          next = inote.descdata + align_power (inote.descsz, 2);

This is incorrect.  According to gABI:

namesz and name
The first namesz bytes in name contain a null-terminated character
representation of the entry's owner or originator. There is no formal mechanism
for avoiding name conflicts. By convention, vendors use their own name, such as
XYZ Computer Company, as the identifier. If no name is present, namesz contains
0. Padding is present, if necessary, to ensure 8 or 4-byte alignment for the
descriptor (depending on whether the file is a 64-bit or 32-bit object). Such
padding is not included in namesz.

descsz and desc
The first descsz bytes in desc hold the note descriptor. The ABI places no
constraints on a descriptor's contents. If no descriptor is present, descsz
contains 0. Padding is present, if necessary, to ensure 8 or 4-byte alignment
for the next note entry (depending on whether the file is a 64-bit or 32-bit
object). Such padding is not included in descsz.

Here the name field, not namesz, is padded for the note descriptor.  And
the desc field, not descsz, is padded for the next note entry.

But on Linux, .note.ABI-tag and .note.gnu.build-id notes are always aligned
to 4 bytes.  In this case, we should check sh_addralign, instead of using
alignment based on 32-bit or 64-bit objects.

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