VULNERABILITY DETAILS
There is a mismatch in the amount of bytes allocated and then copied into this buffer.
In line 228 the pointer line will be assigned to a buffer of size i+1 and i bytes of data will be copied to the buffer to which line points to. By causing an Integer-Overflow for i+1, malloc(i+1) will be equal to malloc(0). So the i bytes will be copied into a buffer which definitly is less than size i and therefore cause a buffer-overflow. This integer-overflow is possible as len, which is an upper bound for i, is of type size_t. Therefore len may contain integers up to 2^64 on 64-bit systems, but i is of type unsigned integer which, on 64-bit, could only contain smaller integers than 2^64, typically 2^32. 

VERSION
Chrome Version: chromium/chromium/src/base/58ac499a108228937e73a356e48d773951bbb199 
We didn‘t build, but only used the latest commit to master following the manual from here: https://chromium.googlesource.com/chromium/src/+/master/docs/linux_build_instructions.md#Get-the-code


Operating System: Manjaro Linux 17.0

REPRODUCTION CASE
As we used statical analysis we have no input, which triggers the vulnerability, but want to present how this could be exploided. The function, which contains the vulnerability is called evbuffer_readline and gets called for example, whenever a new part of a header of the http protocol is received.
 Assume the bufferlength len, having type size_t, is greater than UINT_MAX, which is possible on 64-bit systems as then size_t can contain integers up to 2^64. Then an adversary could send a headerline with special crafted data which contains no \r or \n until the UINT_MAX character. This one will be set to either \n or \r. Now i will be set to UINT_MAX in line 220. As len is greather than UINT_MAX the first condition will be passed. In the second condition 
line = malloc(i+1) is equal to line = malloc(UINT_MAX + 1), which is equal to 
line = malloc(0). As the malloc(0) return value is implementation dependend and does, for example for gcc not return NULL, the second condition will also be passed. Now in line 233 UINT_MAX characters from data will be copied to the location where line points to, although there is not enough space for this, leading to a buffer-overflow.


While this may be no bug up to now for Chrome it may become a bug as soon as the buffer size will be > UINT_MAX >= 4gb. And it is indead a bug in the libevent library, which could already affect high traffic servers using this library like the tor project, which could specify such a big buffer due to their high load.



Our solution would be to change the type of i to size_t and add a check for overflow:
if (i+1 < 1) {
	return NULL;
}  



This bug was found by Kolja Grassman and Sebastian Walla.