From a978c074e4272bb901fbe4a10de0a7b2af574f17 Mon Sep 17 00:00:00 2001 From: V3n3RiX Date: Tue, 4 May 2021 22:28:33 +0100 Subject: gentoo resync : 04.05.2021 --- sys-libs/musl/Manifest | 1 - .../musl/files/musl-1.2.1-CVE-2020-28928.patch | 114 --------------------- 2 files changed, 115 deletions(-) delete mode 100644 sys-libs/musl/files/musl-1.2.1-CVE-2020-28928.patch (limited to 'sys-libs/musl') 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 -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 -+#include -+#include - - 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(nn) 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 - -- cgit v1.2.3