From ${URL} : Hi all, u-clibc and uclibc-ng is used in several projects[4, 5]. As described here[3], an attacker that controls the length parameter of the `memset' can also control the value of the PC register. The issue is similar to CVE-2011-2702. A patch has been proposed for uclibc-ng[1]. A denial of service proof of concept is available[2]. Thanks, Lucian [1]http://repo.or.cz/uclibc-ng.git/commit/e3848e3dd64a8d6437531488fe341354bc02eaed [2]http://article.gmane.org/gmane.comp.lib.uclibc-ng/27 [3]http://mailman.uclibc-ng.org/pipermail/devel/2016-May/000890.html [4]https://www.uclibc.org/products.html [5]http://www.uclibc-ng.org/ @security: please file the request for the GLSA.
This fix is in uclibc-ng-1.0.16 which is the only version in the tree, except for the live ebuild. So all the vulnerable versions have been removed already.
Hi, I just found this vulnerability independently yesterday. (In reply to Anthony Basile from comment #1) > This fix is in uclibc-ng-1.0.16 which is the only version in the tree, > except for the live ebuild. So all the vulnerable versions have been > removed already. What about sys-libs/uclibc? It's in-tree and not patched. Also, all the ARM-based uClibc crossdev toolchains are affected, I think quite some people use it to statically link stuff. The uClibc ARM tarballs are still affected by this bug [1] too. uClibc's latest release dates back to 15 May 2012, maybe we should estimate the effort of dropping uClibc completely in favor of uClibc-ng. Has it ever been tried? [1] http://distfiles.gentoo.org/experimental/arm/uclibc/
(In reply to Alessandro Di Federico from comment #2) > Hi, I just found this vulnerability independently yesterday. > > (In reply to Anthony Basile from comment #1) > > This fix is in uclibc-ng-1.0.16 which is the only version in the tree, > > except for the live ebuild. So all the vulnerable versions have been > > removed already. > > What about sys-libs/uclibc? It's in-tree and not patched. Also, all the > ARM-based uClibc crossdev toolchains are affected, I think quite some people > use it to statically link stuff. > The uClibc ARM tarballs are still affected by this bug [1] too. > > uClibc's latest release dates back to 15 May 2012, maybe we should estimate > the effort of dropping uClibc completely in favor of uClibc-ng. Has it ever > been tried? > > [1] http://distfiles.gentoo.org/experimental/arm/uclibc/ There is only so much of me to go around. I will be abandoning sys-libs/uclibc in about 1 month. I simply cannot maintain more and do my real life work.
@ Security: Please vote.
Arches and Maintainer(s), Thank you for your work. New GLSA Request filed. Blueness based on your comments can you please post if anyone would like to maintain the package.
(In reply to Yury German from comment #5) > Arches and Maintainer(s), Thank you for your work. > New GLSA Request filed. > > Blueness based on your comments can you please post if anyone would like to > maintain the package. I don't think we can remove uclibc just yet. uclibc-ng has not yet mature to that point. I would say by August I can make a full cleanup.
I removed the pending GLSA: This vulnerability only affects ARM architecture which isn't an architecture with security coverage in Gentoo (see https://www.gentoo.org/support/security/vulnerability-treatment-policy.html). Repository is clean, all done.
