http://seclists.org/oss-sec/2016/q3/126

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].

        libc/string/arm/memset.S


        bugfix: ARM: memset.S: use unsigned comparisons

        The 'BLT' instruction checks for *signed* values. So if a3, length
        parameter of memset, is negative, then value added to the PC will be
        large.

        memset(buf, 0xaa, 0xffff0000) triggers the bug.


The attack is a bit unrealistic, as it requires that the
application that uses uClibc allows a user to control a memory chunk
larger than 2GB.


[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/


References:
https://bugzilla.redhat.com/show_bug.cgi?id=1352459
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6264
http://seclists.org/oss-sec/2016/q3/126
http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-6264.html


Ismail, worth a fix for arm port?