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.
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.