In grep 2.20, grep.c contains: ssize_t fillsize; size_t readsize; [...] fillsize = safe_read (bufdesc, readbuf, readsize); if (fillsize < 0) fillsize = cc = 0; bufoffset += fillsize; fillsize = undossify_input (readbuf, fillsize);
In practice, readsize can be large on a 64-bit machine (more than 2 GB), so that the return value of safe_read(), fillsize, can also be large since a read() is called with readsize as the 3rd argument. But dosbuf.c has: static int undossify_input (char *buf, size_t buflen) { if (! O_BINARY) return buflen; [...] meaning that the potentially large buflen (> 2 GB) is returned as an int, whose usual size is 32 bits only, yielding an integer overflow. undossify_input should be rewritten in such a way that some int's are changed to size_t or ssize_t. Note: This bug is currently not visible under Linux due to a limitation in the kernel (breaking POSIX compliance, BTW): the read() return value is limited to 0x7ffff000. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)