Hi Milian, On Mon, 2022-07-11 at 18:40 +0200, Milian Wolff wrote: > in heaptrack I have code to runtime attach to a program and then > rewrite the > various rel / rela / jmprel tables to intercept calls to malloc & friends. > > This works, but now I have received a crash report for what seems to > be an > invalid DSO file: The jmprel table contains an invalid entry which > points to > an out-of-bounds symbol, leading to a crash when we try to look at > the > symbol's name. > > I would like to protect against this crash by detecting the invalid > symbols. > But to do that, I would need to know the size of the symbol table, > which is > much harder than I would have hoped: > > We have: > > ``` > #define DT_SYMTAB 6 /* Address of symbol table */ > #define DT_SYMENT 11 /* Size of one symbol table > entry */ > ``` > > But there is no `DT_SYMSZ` or similar, which we would need to > validate symbol > indices. Am I overlooking something or is that really missing? Does > anyone > know why? The other tables have that, e.g.: > > ``` > #define DT_PLTRELSZ 2 /* Size in bytes of PLT relocs */ > #define DT_RELASZ 8 /* Total size of Rela relocs */ > #define DT_STRSZ 10 /* Size of string table */ > #define DT_RELSZ 18 /* Total size of Rel relocs > */ > ``` > > Why is this missing for the symtab? > > The only viable alternative seems to be to mmap the file completely > to access > the Elf header and then iterate over the Elf sections to query the > size of the > SHT_DYNSYM section. This is pretty complicated, and costly. Does > anyone have a > better solution that would allow me to validate symbol indices?
I don't know why it is missing, but it is indeed a tricky issue. You really want to know the number of elements (or the size) of the symbol table, but it takes a little gymnastics to get that. Di Chen recently (or actually not that recently, I just still haven't reviewed, sorry!) posted a patch for https://sourceware.org/bugzilla/show_bug.cgi?id=28873 to print out the symbols from the dynamic segment https://sourceware.org/pipermail/elfutils-devel/2022q2/005086.html > PS: eu-elflint reports this for the broken DSOs e.g.: > ``` > $ eu-elflint libQt5Qml.so.5.12 > section [ 3] '.dynsym': symbol 1272: st_value out of bounds > section [ 3] '.dynsym': symbol 3684: st_value out of bounds > section [29] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not > match > .got section size 18340 > section [29] '.symtab': _DYNAMIC symbol size 0 does not match dynamic > segment > size 336 > section [29] '.symtab': symbol 25720: st_value out of bounds > section [29] '.symtab': symbol 27227: st_value out of bounds > ``` > > Does anyone know how this can happen? Is this a bug in the toolchain? Try with eu-elflint --gnu which suppresses some known issues. Also could you show those symbol values (1272, 3684, 25720, 27227) they might have a special type, so their st_value isn't really an address? Cheers, Mark
