On 21/04/16 20:21, none wrote:
As you know
Do we? A reference in support would be needed for
such massive code churn, I think.
--
Jeremy
There’s plenty cve that were due to the assumption that int is enough
for representing sizes and found it working in normal scenarios (until
an attacker found a crafted one).
You take a look from the recent example in openssl (ᴄᴠᴇ‑2016‑0797) to my
own work https://bounty.github.com. It’s really a common mistake
http://stackoverflow.com/a/131833/2284570
Even on architectures were int and size_t use the same number of bits,
there’s still a risk because size_t is unsigned while in is signed
(allowing size_t to contains more data).
The use of size_t prevent most cases of oveflow case because most of the
time the data whose length is represented need to fit in ram (meaning
memory allocation should gracefully fails in way handled by the
program).
I started working on such change and it is not so huge it’s about 360
replacements+another ~30 which should be done in a separate commit for
handling the last case where the result of malloc isn’t checked (due to
a direct call).
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
