[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/22444] New: Incorrect note padding check
From: |
hjl.tools at gmail dot com |
Subject: |
[Bug binutils/22444] New: Incorrect note padding check |
Date: |
Wed, 15 Nov 2017 17:32:11 +0000 |
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.
- [Bug binutils/22444] New: Incorrect note padding check,
hjl.tools at gmail dot com <=
- [Bug binutils/22444] Incorrect note padding check, hjl.tools at gmail dot com, 2017/11/15
- [Bug binutils/22444] Incorrect note padding check, fweimer at redhat dot com, 2017/11/15
- [Bug binutils/22444] Incorrect note padding check, fweimer at redhat dot com, 2017/11/15
- [Bug binutils/22444] Incorrect note padding check, address@hidden, 2017/11/16
- [Bug binutils/22444] Incorrect note padding check, hjl.tools at gmail dot com, 2017/11/16
- [Bug binutils/22444] Incorrect note padding check, hjl.tools at gmail dot com, 2017/11/16
- [Bug binutils/22444] Incorrect note padding check, address@hidden, 2017/11/16
- [Bug binutils/22444] Incorrect note padding check, hjl.tools at gmail dot com, 2017/11/16
- [Bug binutils/22444] Incorrect note padding check, hjl.tools at gmail dot com, 2017/11/16
- [Bug binutils/22444] Incorrect note padding check, hjl.tools at gmail dot com, 2017/11/16