> It seems to me that exim refuses to manipulate stings over 32767 bytes
> long.
> that should be enough to make it safe.
Yeah, the same way git would never face strings larger than 2¹⁶ or
PATH_MAX until I found the way to circumvent this. My point is to had an
additional protections for being sure.
I know exim enforce this better for the client side which is why I
wrote :
> I agree most integers in that case will never grow up to INT_MAX
But the reality is that limitation is not even true everywhere. (you can
check the database side of code or the string handling parts for ᴛʟꜱ
negotiation).
String handling isn’t the only side of the problem, there are also an
another serious issue which is due to the nature on how you wrap malloc.
Let’s take an example among the functions you use for wrapping malloc :
If size on store_malloc_3(int size, const char *filename, int
linenumber) become negative on little 64 bits machine with 32 bits, it
will try to allocate (unsigned long)(2⁶⁴‑(unsigned int)(size)) which
means Exabytes of ʀᴀᴍ and the deamon will gracefully fail (I tested
this).
But the same situation on a big endian machine might result in having
less byte allocated than requested (I mean less than INT_MAX). A
potential case for overflows…
You can check chat I did on
https://github.com/Exim/exim/compare/master...ytrezq:size_t
