Hey there,

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?

Thanks

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?
-- 
Milian Wolff
mail@milianw.de
http://milianw.de