Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 589820 (CVE-2016-6354) - <sys-devel/flex-2.6.1: Buffer overflow in generated code (CVE-2016-6354)
Summary: <sys-devel/flex-2.6.1: Buffer overflow in generated code (CVE-2016-6354)
Status: RESOLVED FIXED
Alias: CVE-2016-6354
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Security
URL: http://www.openwall.com/lists/oss-sec...
Whiteboard: A2 [glsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-27 08:14 UTC by Agostino Sarubbo
Modified: 2017-01-11 13:33 UTC (History)
1 user (show)

See Also:
Package list:
=sys-devel/flex-2.6.1
Runtime testing required: ---
kensington: sanity-check+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2016-07-27 08:14:35 UTC
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.
Comment 1 SpanKY gentoo-dev 2016-08-03 02:36:56 UTC
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 ...
Comment 2 Coacher 2016-08-30 06:31:21 UTC
(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
Comment 3 nvinson234 2016-09-04 16:06:29 UTC
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.
Comment 4 Thomas Deutschmann gentoo-dev Security 2016-11-18 19:26:39 UTC
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?
Comment 5 Thomas Deutschmann gentoo-dev Security 2016-11-29 01:21:25 UTC
@ Arches,

please test and mark stable: =sys-devel/flex-2.6.1
Comment 6 Agostino Sarubbo gentoo-dev 2016-11-29 11:23:03 UTC
amd64 stable
Comment 7 Agostino Sarubbo gentoo-dev 2016-11-29 11:24:04 UTC
x86 stable
Comment 8 Markus Meier gentoo-dev 2016-11-30 19:34:24 UTC
arm stable
Comment 9 Tobias Klausmann gentoo-dev 2016-12-02 14:21:39 UTC
Stable on alpha.
Comment 10 Agostino Sarubbo gentoo-dev 2016-12-19 14:37:00 UTC
sparc stable
Comment 11 Agostino Sarubbo gentoo-dev 2016-12-19 15:13:50 UTC
ia64 stable
Comment 12 Agostino Sarubbo gentoo-dev 2016-12-20 09:46:19 UTC
ppc stable
Comment 13 Agostino Sarubbo gentoo-dev 2016-12-22 09:36:23 UTC
ppc64 stable
Comment 14 Jeroen Roovers gentoo-dev 2017-01-09 13:52:56 UTC
Stable for HPPA.
Comment 15 Thomas Deutschmann gentoo-dev Security 2017-01-09 14:06:44 UTC
New GLSA request filed.


@ Maintainer(s): Please drop =sys-devel/flex-2.5.39-r1.
Comment 16 GLSAMaker/CVETool Bot gentoo-dev 2017-01-11 12:42:22 UTC
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).
Comment 17 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2017-01-11 12:45:54 UTC
reopened for cleanup
Comment 18 Lars Wendler (Polynomial-C) gentoo-dev 2017-01-11 13:30:33 UTC
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
Comment 19 Thomas Deutschmann gentoo-dev Security 2017-01-11 13:33:18 UTC
@ Maintainer(s): Thank you for your work!

Repository is now clean, all done.