"An exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data."
It's not not clear that upstream actually agree it's a security bug.
They have not formally disputed the CVE though.
this got fixed upstream by these two commits:
found via https://sourceware.org/bugzilla/show_bug.cgi?id=25620#c25
they apply to glibc-2.30-r8 , but I could imagine glibc-2.31-r3 being the better place to backport this since 2.30 is already stable
(In reply to tt_1 from comment #1)
> this got fixed upstream by these two commits:
These commits only added tests. The vulnerability was really fixed only recently:
this got fixed in glibc-2.31 patchset8:
sys-libs/glibc: 2.31 bump to patchset 8, finally stable candidate
* arm: fix for CVE-2020-6096
* en_US: minimize changes to date_fmt (backport from 2.32)
* x86-64: fix avx2 strncmp offset compare condition check
* ia64: fix miscompilation on gcc-10
The bug has been referenced in the following commit(s):
Author: Andreas K. Hüttel <email@example.com>
AuthorDate: 2020-10-30 19:27:56 +0000
Commit: Andreas K. Hüttel <firstname.lastname@example.org>
CommitDate: 2020-10-30 19:29:02 +0000
package.mask: extend glibc mask to <2.31-r6
Signed-off-by: Andreas K. Hüttel <email@example.com>
profiles/package.mask | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
All masked. Security please proceed. No cleanup.
This issue was resolved and addressed in
GLSA 202101-20 at https://security.gentoo.org/glsa/202101-20
by GLSA coordinator Aaron Bauman (b-man).