summaryrefslogtreecommitdiffstats
path: root/tests
diff options
context:
space:
mode:
authorMark Wielaard <[email protected]>2018-06-12 12:54:35 +0200
committerMark Wielaard <[email protected]>2018-06-22 17:52:34 +0200
commitdd813335c352adb53972bdc63495650dba0c987f (patch)
treedec852640f6c473f89895a33dca5e7afa283b02e /tests
parentc1990d36cfe37a30bcc49422c37a6767fd190559 (diff)
libelf: Don't return unaligned data returned from elf_getdata[_rawchunk].
For i386 and x86_64 we allow some unaligned data accesses. We also return unaligned data from elf_getdata[_rawchunk]. But that might go wrong if we then access the ELF types inside. When build with gcc -O3 for example the compiler might vectorize loops accessing ELF words or types. The instructions used do require the data is naturally aligned. If the function returnes unaligned data the program will segfault and crash. This happens for example with the code in dwfl_module_getdwarf.c that tries to iterate over the hash buckets gotten through elf_getdata_rawchunk based on the DT_[GNU]_HASH value. This only happens when the underlying ELF file is mmapped, and it is meant as optimization so that we don't have to copy data first so that it is correctly aligned. In most cases the data is already naturally aligned though. But it might not be for non-native ELF files. Given that it might even happen in our own code base and these are public functions that can be used by code that might rely on the data returned being correctly aligned for the ELF data type requested just always return correctly aligned data. Signed-off-by: Mark Wielaard <[email protected]>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions