Project

General

Profile

Bug #4959

completely discarded merged string sections will corrupt output objects

Added by Rich Lowe over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
tools - gate/build tools
Start date:
2014-07-03
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

If an input object contains a mergable string table of 0 size (not even containing the NUL string), we'll produce an output object with a corrupt string table, or trip an assert:

Assertion failed: shdr->sh_info == SYMTAB_LOC_CNT(ofl), file ../common/update.c, line 1959, function update_osym

This seems to be because this input section deserves to be discarded (and would be), but the new merged section we create for it will have size 1 (because it will always contain the NUL string) and thus will partially persist.

We certainly should not be producing merged sections if there are no input strings.
It is likely we also should not be getting nearly so muddled in the case where we do (we should likely be producing just a useless output section, not one that corrupts the string table).

In the test case I have, unfortunately, the string table corrupt causes us to have two output sections named ".comment", which makes following the debug output from the link-editor challenging.

#1

Updated by Rich Lowe over 6 years ago

The reason this screws us more is -z ignore processing.

What happens is that because the input .debug_str is of 0 size, it is discarded, so when we update the section count for ignore processing we remove from the shstrtab the name ".debug_str", decrements the section count, etc. Unfortunately, the newly created merged section still exists, and this throws all our counts off.

This is likely a problem even in the case of a non-0 sized input section iff these sections are completely unreferenced, they would still be subject to ignore processing and still enter this state.

That's proving rather hard to test, however.

#2

Updated by Rich Lowe over 6 years ago

The reason that this section can be discarded while leaving the merge section is that while we will only create merge sections if there is at least one input section which is not discarded, that logic does not account for an entire input file being discarded (which doesn't, or has not yet, set FLG_IS_DISCARD on the input sections).

We should have a check similar to the one in adjust_os_cnt(). We should probably also not create merge sections for empty (and thus invalid) input string tables.

#3

Updated by Rich Lowe over 6 years ago

  • Subject changed from input objects with empty mergable string sections will corrupt output objects to completely discarded merged string sections will corrupt output objects
#4

Updated by Rich Lowe over 6 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 70
#5

Updated by Electric Monk over 6 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 70 to 100

git commit d9c5840bd764434fd93f85a52eb4cbc24bff03da

commit  d9c5840bd764434fd93f85a52eb4cbc24bff03da
Author: Richard Lowe <richlowe@richlowe.net>
Date:   2014-07-19T23:07:28.000Z

    4959 completely discarded merged string sections will corrupt output objects
    Reviewed by: Dan McDonald <danmcd@omniti.com>
    Reviewed by: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Approved by: Garrett D'Amore <garrett@damore.org>

Also available in: Atom PDF