Bug #1301
closedld crashes with '-z ignore' due to a null data descriptor
100%
Description
When ld is passed -z ignore
it, in certain cases, will temporarily create output sections with no data descriptors.
This trips an assert in ld introduced with the fix for #308, and otherwise crashes with a write to NULL+0x20:
fffffd7fffdff590 libld.so.4`ld32_create_outfile+0x79c() fffffd7fffdff5e0 libld.so.4`ld32_main+0x5e7() fffffd7fffdff620 main+0xb9() fffffd7fffdff630 0x401efc()
libld.so.4`ld32_create_outfile+0x797: call -0x2a48c <PLT=libelf.so.1`elf_getdata> libld.so.4`ld32_create_outfile+0x79c: movq %r14,0x20(%rax) > <rax=K 0 > ::offsetof Elf_Data d_align offsetof (Elf_Data, d_align) = 0x20, sizeof (...->d_align) = 8
This is as we try to increase the alignment of that empty section to match those following it, per #308.
This is because in ld_create_outfile the output .data section already exists, and so while we mark it discarded, we don't have the opportunity to elide it from the list of output section descriptors, it is instead dropped later, while re-initializing section descriptors we prune any output descriptor with a NULL os_scn.
We should be sure that a sections data descriptor is not-NULL before assigning to its d_align. If the first data descriptor is NULL, I believe it is safe to assume that the entire section is discarded, the logic being that with no data descriptors it also has no size, alignment, etc.
Given we got into this bug, however, due to a set of asserts that a wide range of software failed to trip, I'm not entirely sure how safe it is to assume this.
Related issues
Updated by Rich Lowe about 12 years ago
- Category set to cmd - userland programs
- Status changed from New to In Progress
- % Done changed from 0 to 50
- Tags deleted (
needs-triage)
Updated by Rich Lowe about 12 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Resolved in r13438 commit:084a34091b25