Make match_so_flags a bit mre robust
I cannot say that I understand the purpose behind the match_so_flags function. Is it supposed to be an exhaustive check? Just a quick check? Is it always required to find the DSO which would be used by the current process? Should there be an overwrite? In any case, the current way seems to be wholly inadequate. It somehow assumes a specific order of the DSO in the list read from the ld.so cache. That's fragile at best. In the case of one of my machines, I run a x86-64 process and try to find a symbol in libc. The first DSO returned in the cache matching "libc.so" is /libx32/libc.so.6 (i.e., the x32 version of libc). Using the file works but the DSO is not used. I assume the idea behind the short form "c" for the module name is to use the DSO of the same type as the running process. As is all platforms not matching the listed 64-bit platforms are blindly accepted. I suggest at the very least to check for the case of the non-64-bit DSO in the cache to check that the running program is also 32-bit. This patch does this. In the longer run a more robust check should be implemented which compares the current process' ELF header with that of the found DSO. If this is the desired direction let me know and I'll come up with a patch.
Showing
Please register or sign in to comment