Mark, On Tue, Nov 14, 2023 at 4:57 AM Mark Wielaard <m...@klomp.org> wrote:
> Urgh, I had no idea NULL + ... was technically undefined behavior. ISO/IEC 9899:201x 6.5.6p8 When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. ... If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined. > It would be slightly nicer if > we could just do the computation after checking map_address != NULL > (since ehdr is only used after such a check). That would require > rearranging some of the if statements. Does that make the code too > complicated? I tried it, and it does: we need both "map_addr != 0" and "ehdr is properly aligned", but we can't compute the latter before evaluating the former, and we have the else clause when either condition fails. I can fix this with a goto, or a helper variable, but the current solution of keeping ehdr as uintptr_t is much simpler. It also reduces the casting and line wrapping required :-) > Also this only resolves the issue for the 64bit ELF case. Just above > this code is basically the same code for 32bit ELF. That code also > needs to be fixed. Sorry I missed that. Revised patch attached. Thanks, -- Paul Pluzhnikov
0001-Fix-computations-with-potentially-NULL-pointer.patch
Description: Binary data
