m4b
Parsing fails when the TLS index is in the zeroed area of a section
While processing DLLs from NVidia's graphics drivers I stumbled upon this file which failed to parse correctly. What happens at the point of error is the following:
- We're parsing the TLS section and we found a non-zero TLS index address so we're looking up its contents here
- The value of the TLS index address is
0xdabe90and the data section spans0x175000..0xdac178so it should work, but it fails to find it instead and moves on to the other sections, ultimately failing because it can't find a section to which the address belongs to - The reason why
utils::find_offset()fails even though the address falls within the section, is that it checks if the address falls between the beginning of the section and the beginning of the section plus the raw size, which is0x3800in this case. So it checks whether the TLS index address size is between0x175000..0x178800, which it isn't and thus fails.
The expected behavior of this particular code should be that the TLS index is simply set to zero, since the address points to an area of memory which is set to zero.
This seems to make sense from a logical perspective, given that Microsoft documentations mentions that this area is populated by the loader, so the section won't contain the actual value until it's loaded. It thus makes sense for it to be in a zeroed area.
I wonder if this might be a potential issue in more areas of the code. utils::find_offset() will always fail if the offset falls within a section, but not within the area populated in the file, however those offsets aren't invalid, they will be once the module is loaded into memory. It's just that they'll point to data that contain zeroes.
are you able to resolve this or know of a patch you could contribute that can fix the underlying issue?
