This vulnerability is disputed by upstream maintainers with negligible security impact.
The stack consumption problem is caused by the mark_beginning_as_normal function making
recursive calls to itself. The crash occurs in flex itself, not in the scanner produced
by flex. The protection against exploit is to not run flex setuid, which is already the
default behavior. Stack exhaustion from exceptionally long garbage input to flex is not
considered a security concern.
https://security-tracker.debian.org/tracker/CVE-2019-6293
https://github.com/westes/flex/issues/414