bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/16199] New: Objcopy crash when section alignment is zero


From: goldstei at ugcs dot caltech.edu
Subject: [Bug binutils/16199] New: Objcopy crash when section alignment is zero
Date: Thu, 21 Nov 2013 00:58:02 +0000

http://sourceware.org/bugzilla/show_bug.cgi?id=16199

            Bug ID: 16199
           Summary: Objcopy crash when section alignment is zero
           Product: binutils
           Version: 2.25 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: goldstei at ugcs dot caltech.edu

Created attachment 7287
  --> http://sourceware.org/bugzilla/attachment.cgi?id=7287&action=edit
Patch to avoid division by zero

When making a copy of an ARM 32 bit elf file generated by IAR. I found that
when copying a section we can get to a situation where, in the function
assign_file_posistion_for_load_sections() the p_align_valid flag is 1 when the
p_align flag is set to 0. This will cause a divide by zero error in
vma_page_aligned_bias(). 

I'm not sure if the p_align_valid flag should be set when the alignment is 0;
however I did make a patch that fixes the crash, by simply not calling
vma_page_aligned_bias().

Here is readelf's dump of the section headers that caused the crash,
specifically Fill1:
---
Section Headers:
  [Nr] Name
       Type            Addr     Off    Size   ES   Lk Inf Al
       Flags
... useless lines ...
  [25] Fill1
       PROGBITS        000060d8 554668 000028 01   0   0  0
       [00000006]: ALLOC, EXEC
  [26] Fill2
       PROGBITS        00089240 554690 016db8 01   0   0  0
       [00000006]: ALLOC, EXEC
---
These sections are filled with 0xffffffff. The ARM ELF spec does state that the
alignment of executable sections must be at least 32-bits. These contain no
code, so in that sense, the output may be in violation of the ELF spec. Still,
I think it makes sense for objcopy to behave defensively in this case.

I've attached a patch. If needs be, I can also generate a file that displays
the behavior.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]