As already mentioned in the email to Petr Machata, 
potential security fixes between v2.5.33 and v2.5.35
versions of flex might be these:

a, better checking after yyalloc/yyrealloc (resolves bug #1595967)
http://sourceforge.net/tracker/?func=detail&aid=1595967&group_id=97492&atid=618177

b, flex better escapes filenames with special characters in them
   (resolves bug #1623600)
http://sourceforge.net/tracker/?func=detail&aid=1623600&group_id=97492&atid=618177

c, a memory leak was plugged(resolves bug #1601111)
http://sourceforge.net/tracker/?func=detail&aid=1601111&group_id=97492&atid=618177 

Where a, and b, are 'security hardening' fixes, c, is buffer
overflow with reproducer here:
http://sourceforge.net/tracker/download.php?group_id=97492&atid=618177&file_id=203983&aid=1601111

and patch here:
http://sourceforge.net/tracker/download.php?group_id=97492&atid=618177&file_id=204150&aid=1601111

Mailed Petr for his review of conditions and impact of the issue.

From looking at this bug, we end up writing two extra 0's into the malloc'd buffer.

This isn't going to be an arbitrary code execution issue on RHEL4+ where we have memory protections that would simply cause these two extra writes to crash.

(In reply to comment #1)
> a, better checking after yyalloc/yyrealloc (resolves bug #1595967)
> http://sourceforge.net/tracker/?func=detail&aid=1595967&group_id=97492&atid=618177

This issue did not affect flex versions (2.5.4a) in Red Hat Enterprise Linux 3, 4 and 5.  All alloc/realloc calls in flex.skl in 2.5.4a are followed by a allocation failure check.

> b, flex better escapes filenames with special characters in them
>    (resolves bug #1623600)
> http://sourceforge.net/tracker/?func=detail&aid=1623600&group_id=97492&atid=618177

This does not seem to have any security implications, those extra lines are added as a hint to be able to report more useful error pointing to flex source lines.

> c, a memory leak was plugged(resolves bug #1601111)
> http://sourceforge.net/tracker/?func=detail&aid=1601111&group_id=97492&atid=618177

Not a memory leak, rather a buffer overflow.

> and patch here:
> http://sourceforge.net/tracker/download.php?group_id=97492&atid=618177&file_id=204150&aid=1601111

Different patch was committed to upstream CVS:
  http://flex.cvs.sourceforge.net/viewvc/flex/flex/flex.skl?r1=2.195&r2=2.196

(note: this fix does not check realloc return value, see a, above)

(In reply to comment #2)
> From looking at this bug, we end up writing two extra 0's into the malloc'd
> buffer.

Doing more tests with the linked bogofilter reproducer, this is not an off-by-two error as SF.net bug may suggest.  This actually does not seem to be flex flaw at all, rather a bogofilter bug.  bogofilter provides its own yyinput function for reading input.  This custom input function produces unexpected result.  Quoting flex documentation:

  The nature of how it gets its input can be controlled by defining the
  YY_INPUT macro. The calling sequence for YY_INPUT() is
  YY_INPUT(buf,result,max_size). Its action is to place up to max_size
  characters in the character array buf and return in the integer variable
  result either the number of characters read or the constant YY_NULL (0 on
  Unix systems) to indicate `EOF'.

In the provided test case, yyinput is called with max_size == 61 and returns 91, i.e. more than expected.  This leads to buffer overflow.

All flex memory allocations seems to take the need for extra two YY_END_OF_BUFFER_CHAR bytes correctly into an account.

Closing as notabug based on the analysis above.  Bugs fixed in 2.5.35 either did not affect flex version in Red Hat Enterprise Linux 3, 4, and 5, or were not flex security issues.

Current Fedora and RHEL-6 flex is based on upstream 2.5.35.

Upstream bug was filed for bogofilter's misbehaving yyinput:
http://sourceforge.net/tracker/?func=detail&aid=3071774&group_id=62265&atid=499997