From ${URL} : flex upstream change some integer type in 2.5.36[1] to unsigned integer types (size_t). Especially the num_to_read variable in yy_get_next_buffer is critical, because 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 also remote usable, it depends on the software that is build using flex. We noticed for example, that bogofilter segfaults sometimes depending on the incoming mail. Upstream already noticed that this may be a problem[2] but did not escalate it as a security issue. Upstream also changed some other type back from size_t to int (for example in [3]) so maybe it is not sufficient to only change num_to_read back to int. The upstream fix is contained in 2.6.1, but there are more integer type fixes in the master branch of flex (currently not in a released version). As the issue is in the generated code during compile time, it is not sufficient to fix flex, but all binaries using flex as build-dependency may need a rebuild after fixing flex. Additinally there may be packages, that supply the generated source in the release-tar and do not use flex during building. Could you please assign a CVE for this issue? Thanks, Alexander Sulfrian 1: https://github.com/westes/flex/commit/9ba3187a537d6a58d345f2874d06087fd4050399 2: https://github.com/westes/flex/commit/a5cbe929ac3255d371e698f62dc256afe7006466 3: https://github.com/westes/flex/commit/7a7c3dfe1bcb8230447ba1656f926b4b4cdfc457 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
what fixes, if any, need to be added to 2.6.1 ? we have that in the tree already and can simply stabilize it. that said, as noted in the report, it doesn't help with generated lexers that are shipped in tarballs. in Gentoo, we haven't been regenerating them (much like we don't regen autotools all the time). so need a full tree audit somehow. i don't think we have anything like Debian's giant source indexer ...
(In reply to SpanKY from comment #1) > what fixes, if any, need to be added to 2.6.1 ? we have that in the tree > already and can simply stabilize it. Please note that flex-2.6.1 introduced some type changes compared to 2.6.0 [1] effectively reverting some types back to pre-2.5.36 behaviour [2]. This can lead to problems similar to bug 579490. [1]: https://github.com/westes/flex/commit/7a7c3dfe1bcb8230447ba1656f926b4b4cdfc457 [2]: https://github.com/westes/flex/commit/9ba3187a537d6a58d345f2874d06087fd4050399
I haven't had much chance to look into the actual code, but based on this bug's comments it sounds like defining yyleng as an ssize_t (signed size_t) might be the best approach. The kernel functions read(2) and write(2) already use this type as their return type, so there is some precedence here.
CVE-2016-6354 was official fixed in v2.6.1 which is available in Gentoo repository since https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-devel/flex?id=2b3a407b661078b2b116ee79dc7a10486d16f3a4 @ Maintainer(s): Is =sys-devel/flex-2.6.1 ready for stabilization or is bug 598186 blocking?
@ Arches, please test and mark stable: =sys-devel/flex-2.6.1
amd64 stable
x86 stable
arm stable
Stable on alpha.
sparc stable
ia64 stable
ppc stable
ppc64 stable
Stable for HPPA.
New GLSA request filed. @ Maintainer(s): Please drop =sys-devel/flex-2.5.39-r1.
This issue was resolved and addressed in GLSA 201701-31 at https://security.gentoo.org/glsa/201701-31 by GLSA coordinator Aaron Bauman (b-man).
reopened for cleanup
commit 920eefba5481eef110406a2b6859c4edd0b4c48e Author: Lars Wendler <polynomial-c@gentoo.org> Date: Wed Jan 11 14:14:48 2017 sys-devel/flex: Security cleanup (bug #589820). Package-Manager: Portage-2.3.3, Repoman-2.3.1
@ Maintainer(s): Thank you for your work! Repository is now clean, all done.
