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.

-- 
Best regards,
Thilo Schulz