Error processing recent ELF .debug files from Fedora

[gabrielesvelto]

While processing debug information extracted from Fedora 34 packages I came across some ELF files that symbolic doesn't seem to parse correctly. This one for example:

libc-2.32.9000.so.debug

Parsing it throws an ElfError without any further information. I originally ran into this as an issue to our own dump_syms replacement tool.

[mitsuhiko]

The error reported comes from scroll:

ElfError {
    source: Some(
        Scroll(
            TooBig {
                size: 577023735145496576,
                len: 12039064,
            },
        ),
    ),
},

The error comes straight from the call to the elf parser:

https://github.com/getsentry/symbolic/blob/98e1b7a0725b8d279e0100dc3c50cb93a35c98cf/symbolic-debuginfo/src/elf.rs#L73-L78

My hunch is that this is a bug in goblin.

[mitsuhiko]

A reloc section is failing to parse:

https://github.com/m4b/goblin/blob/15e99d00407f8d9e184a7d03cb1ed4f89a5eeecf/src/elf/mod.rs#L285-L286

[src/elf/mod.rs:286] dyn_info.jmprel = 0
[src/elf/mod.rs:286] dyn_info.pltrelsz = 577023735145496576

Evidently pltrelsz seems wrong. I wonder if goblin reads it wrong or if the values are bad. Generally this is a stupid case because if the file is bad the parser currently assumes that the entire file is trash where in reality just a part of it is :(

[gabrielesvelto]

Note that this started happening only recently, it might have been triggered by a change Fedora's tooling. The ELF file could be buggy for all I know, but most likely it's using some new fancy stuff; I've already see it happen with GNU DWARF extensions and the like in the past.

[mitsuhiko]

A very brief look into this would indicate that the file itself is bad but we should do some more digging. That said I think this should be filed against goblin.

@jan-auer didn't we already have similar cases before where parts of the file were bad but we kept on processing the file to some degree?

[jan-auer]

Yes, we had that, but if we fail to parse the header we always had to bail out. We could argue that goblin shouldn't parse relocations eagerly, but in the past I've just tried to fix the issue upstream.

[Swatinem]

I tried reproducing this, and it looks like time and dependency updates solved this problem.

Running object_debug gives me this:

Inspecting .../libc-2.32.9000.so.debug
File format: elf
Objects:
 - x86_64: 1298b619-35bf-d301-854f-be7bbb08c80d
   code id:      19b69812bf3501d3854fbe7bbb08c80d1ce8c9dc
   object kind:  debug companion
   load address: 0x0
   symbol table: false
   debug info:   true
   unwind info:  false
   is malformed: true

And symcache_debug:

SymCache {
    version: 8,
    debug_id: DebugId {
        uuid: "1298b619-35bf-d301-854f-be7bbb08c80d",
        appendix: 0,
    },
    arch: Amd64,
    files: 1504,
    functions: 3747,
    source_locations: 132139,
    ranges: 129035,
    string_bytes: 73231,
}

So by now we process this just fine 🎉

[Swatinem]

Oh wait a second… It says is malformed: true, though I can still construct a symcache from it 🤔

[Swatinem]

The is malformed check was introduced in https://github.com/getsentry/symbolic/pull/434, the purpose of which is to be as lenient as possible when parsing ELF files, which I guess proves the entire point of that PR :-)

The original goal of being able to process the file into a SymCache works, so all is good.