On Tuesday 10 June 2014 11:48:15 Mark Wielaard wrote:
On Mon, 2014-06-09 at 21:05 +0200, Thilo Schulz wrote:
When adding data to existing sections in ELF files, libelf may corrupt those sections, i.e. overwrite the existing data if certain conditions are met.
If an Elf_Scn structure has seen a call to elf_rawdata(scn) before but no call to elf_getdata(scn), scn->read_data flag is set, but not scn->data_list_rear.
Do you happen to have a small testcase that shows the buggy behavior?
Sure. This is an excerpt from the final program. A short word on what it is supposed to do in my practical application: I am doing a project for the AVR platform, which is mixed C/assembly. For command parser functions that are called out of assembly into C code, I need to replace the final return statements with rjmps back to program code in an object file generated from my assembly. So I want to add new symbols and relocations to a cmd.o file.
Find as attachment a simple program, which checks for the presence of the two symbols cmd_response and cmd_noresponse and adds them if they don't exist. Since the AVR architecture is 8 bit, I am only using Elf32_ structures throughout, so you may need to compile test .o objects with -m32 for the test program to work on them.
I was wondering whether we want to check scn->rawdata.s directly, or if we could rely on ELF_F_FILEDATA being set for scn->flags?
Seems reasonable though I don't know the code as well as you do I guess.
As a further note: A similar bug, albeit for slightly different reasons, occurs when adding relocations. Adding a relocation with elf_newdata() then elf_update() results in the old data being "forgotten" if there was no elf_getdata() call before to load that data into memory. The cause is a bit different because in this case, there was not a call to elf_rawdata() before and this still happened. I imagine, this might also be a problem for string tables.