gentoo resync : 04.05.2021

2 files changed, 0 insertions, 115 deletions

diff --git a/sys-libs/musl/Manifest b/sys-libs/musl/Manifest
index 545efc84a487..b2e82bf3ecc7 100644
--- a/sys-libs/musl/Manifest
+++ b/sys-libs/musl/Manifest
@@ -1,5 +1,4 @@
 AUX ldconfig.in 2552 BLAKE2B c94f9900e8582d707519171c4b61079c801b60c555677b1740b04adbdec9645578b9a8fc91f11413072568f316c795e46a332970f3d2dde5272b0c49a5d60a78 SHA512 59f1b57361196363d3f127366764f05d26c23dbe3d3dbcdba9bd3c8ca26a671fd713b96d31c509d22805c57ada2b596d979a3f5795bcf0a4d3ac7d168f3bf377
-AUX musl-1.2.1-CVE-2020-28928.patch 3787 BLAKE2B 25919e7bc18eef643a53bb1be1ed11b8385462c25a991ad306bc2275d523cb64e41a45f5e379de47ecfc59beac773cf8515b3130b68472905007dc49a9342da6 SHA512 07bd31861fa123e55800c9e685ee662b6d80892fdfed943893c22c5e4bd2c283d475a5714823db15c95f343af9ef2290543780fdeadcc2df79c7954a5b68de3d
 AUX stack_chk_fail_local.c 1798 BLAKE2B 380bcbb920bd40a5185246621ba93716f27d61cd0077cd796ff267e10c534c9cc64982b2a66c89b61395dc93d67dae77e8c59908f65f2903f16016180cf94bbb SHA512 bb0bdd7f205d57771920c7ea898c1f84a55d6f90ddd1f8203bfeed98d13ccefa6f68d5fd1c0761321b2732ca928ca81b425e3fe8321c936d1316dea6f1930091
 DIST getconf.c 11614 BLAKE2B ba49a573fc16d51780a0b0b81fbf7b64a1142f1dbad203c9609a59b6b07e7404f676c415383ae88c0aede95694821f6ee381bffd93cc3330501e17dc07d122bd SHA512 0d80f37b34a35e3d14b012257c50862dfeb9d2c81139ea2dfa101d981d093b009b9fa450ba27a708ac59377a48626971dfc58e20a3799084a65777a0c32cbc7d
 DIST iconv.c 2577 BLAKE2B 070ca87b30c90ab98c27d5faf7a2fcb64ff7c67ca212ee6072165b2146979c551f714954dbd465462a171837c59b6ea027e0206458a2df0f977e45f01be3ce48 SHA512 9d42d66fb1facce2b85dad919be5be819ee290bd26ca2db00982b2f8e055a0196290a008711cbe2b18ec9eee8d2270e3b3a4692c5a1b807013baa5c2b70a2bbf
diff --git a/sys-libs/musl/files/musl-1.2.1-CVE-2020-28928.patch b/sys-libs/musl/files/musl-1.2.1-CVE-2020-28928.patch
deleted file mode 100644
index 9797e92ec423..000000000000
--- a/sys-libs/musl/files/musl-1.2.1-CVE-2020-28928.patch
+++ /dev/null
@@ -1,114 +0,0 @@
-https://bugs.gentoo.org/755695
-https://git.musl-libc.org/cgit/musl/patch/?id=3ab2a4e02682df1382955071919d8aa3c3ec40d4
-From 3ab2a4e02682df1382955071919d8aa3c3ec40d4 Mon Sep 17 00:00:00 2001
-From: Rich Felker <dalias@aerifal.cx>
-Date: Thu, 19 Nov 2020 17:12:43 -0500
-Subject: rewrite wcsnrtombs to fix buffer overflow and other bugs
-
-the original wcsnrtombs implementation, which has been largely
-untouched since 0.5.0, attempted to build input-length-limiting
-conversion on top of wcsrtombs, which only limits output length. as
-best I recall, this choice was made out of a mix of disdain over
-having yet another variant function to implement (added in POSIX 2008;
-not standard C) and preference not to switch things around and
-implement the wcsrtombs in terms of the more general new function,
-probably over namespace issues. the strategy employed was to impose
-output limits that would ensure the input limit wasn't exceeded, then
-finish up the tail character-at-a-time. unfortunately, none of that
-worked correctly.
-
-first, the logic in the wcsrtombs loop was wrong in that it could
-easily get stuck making no forward progress, by imposing an output
-limit too small to convert even one character.
-
-the character-at-a-time loop that followed was even worse. it made no
-effort to ensure that the converted multibyte character would fit in
-the remaining output space, only that there was a nonzero amount of
-output space remaining. it also employed an incorrect interpretation
-of wcrtomb's interface contract for converting the null character,
-thereby failing to act on end of input, and remaining space accounting
-was subject to unsigned wrap-around. together these errors allow
-unbounded overflow of the destination buffer, controlled by input
-length limit and input wchar_t string contents.
-
-given the extent to which this function was broken, it's plausible
-that most applications that would have been rendered exploitable were
-sufficiently broken not to be usable in the first place. however, it's
-also plausible that common (especially ASCII-only) inputs succeeded in
-the wcsrtombs loop, which mostly worked, while leaving the wildly
-erroneous code in the second loop exposed to particular non-ASCII
-inputs.
-
-CVE-2020-28928 has been assigned for this issue.
----
- src/multibyte/wcsnrtombs.c | 46 +++++++++++++++++++---------------------------
- 1 file changed, 19 insertions(+), 27 deletions(-)
-
-diff --git a/src/multibyte/wcsnrtombs.c b/src/multibyte/wcsnrtombs.c
-index 676932b5..95e25e70 100644
---- a/src/multibyte/wcsnrtombs.c
-+++ b/src/multibyte/wcsnrtombs.c
-@@ -1,41 +1,33 @@
- #include <wchar.h>
-+#include <limits.h>
-+#include <string.h>
- 
- size_t wcsnrtombs(char *restrict dst, const wchar_t **restrict wcs, size_t wn, size_t n, mbstate_t *restrict st)
- {
--	size_t l, cnt=0, n2;
--	char *s, buf[256];
- 	const wchar_t *ws = *wcs;
--	const wchar_t *tmp_ws;
--
--	if (!dst) s = buf, n = sizeof buf;
--	else s = dst;
--
--	while ( ws && n && ( (n2=wn)>=n || n2>32 ) ) {
--		if (n2>=n) n2=n;
--		tmp_ws = ws;
--		l = wcsrtombs(s, &ws, n2, 0);
--		if (!(l+1)) {
--			cnt = l;
--			n = 0;
-+	size_t cnt = 0;
-+	if (!dst) n=0;
-+	while (ws && wn) {
-+		char tmp[MB_LEN_MAX];
-+		size_t l = wcrtomb(n<MB_LEN_MAX ? tmp : dst, *ws, 0);
-+		if (l==-1) {
-+			cnt = -1;
- 			break;
- 		}
--		if (s != buf) {
--			s += l;
-+		if (dst) {
-+			if (n<MB_LEN_MAX) {
-+				if (l>n) break;
-+				memcpy(dst, tmp, l);
-+			}
-+			dst += l;
- 			n -= l;
- 		}
--		wn = ws ? wn - (ws - tmp_ws) : 0;
--		cnt += l;
--	}
--	if (ws) while (n && wn) {
--		l = wcrtomb(s, *ws, 0);
--		if ((l+1)<=1) {
--			if (!l) ws = 0;
--			else cnt = l;
-+		if (!*ws) {
-+			ws = 0;
- 			break;
- 		}
--		ws++; wn--;
--		/* safe - this loop runs fewer than sizeof(buf) times */
--		s+=l; n-=l;
-+		ws++;
-+		wn--;
- 		cnt += l;
- 	}
- 	if (dst) *wcs = ws;
--- 
-cgit v1.2.1
-