It was found that flex incorrectly resized the num_to_read variable in yy_get_next_buffer. The buffer is resized if this value is less or equal to zero. With special crafted input it is possible, that the buffer is not resized if the input is larger than the default buffer size of 16k. This allows a heap buffer overflow. It may be possible to exploit this remotely, depending on the application that is build using flex. References: http://seclists.org/oss-sec/2016/q3/97 Upstream patch: https://github.com/westes/flex/commit/a5cbe929ac3255d371e698f62dc256afe7006466
Created flex tracking bugs for this issue: Affects: fedora-all [bug 1360744]
flex-2.6.0-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
This flaw was introduced in flex-2.5.36, fixed in 2.6.1.
Testing with flex-2.5.37 on rhel-7 and using a simple lexer that consumes arbitrarily long tokens, I have been unable to cause a segmentation fault or oob read (using valgrind and clang/asan). Instrumenting the generated lex.yy.c to track yyalloc()/yyrealloc(), the lexer's behaviour seems to be safe. I think the potential security impact is mitigated by the following code immediately after the affected loop, which constrains the max number of bytes read to 8192: if ( num_to_read > YY_READ_BUF_SIZE ) num_to_read = YY_READ_BUF_SIZE; Once num_to_read reaches 0, the buffer is reallocated correctly and filled in 8192-byte (or smaller) chunks. Looks like this may not be a security flaw at all, though this analysis should be confirmed with upstream.