Sure, Tim. I think there is no need to send the patch again to upgrade apr-util to 1.6.3 since, Steve Sakoman has already sent review request for some set of patches for kirkstone and these also include the patch for apr-util: update 1.6.1 -> 1.6.3 version. These patches are currently available at “stable/kirkstone-nut” branch.
http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=stable/kirkstone-nut&id=e24b38a14b3520648ec418783fb74fcf61df7ff2 Please let me know if my above understanding is correct or not. Best Regards, Narpat From: Tim Orling<mailto:ticot...@gmail.com> Sent: 22 February 2023 07:37 To: Mali, Narpat<mailto:narpat.m...@windriver.com> Cc: Polampalli, Archana<mailto:archana.polampa...@windriver.com>; G Pillai, Hari<mailto:hari.gpil...@windriver.com>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> Subject: Re: [OE-core][kirkstone][PATCH 1/1] apr-util: fix for CVE-2022-25147 CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, Feb 21, 2023 at 5:20 AM Narpat Mali <narpat.m...@windriver.com<mailto:narpat.m...@windriver.com>> wrote: Integer Overflow or Wraparound vulnerability in apr_base64 functions of Apache Portable Runtime Utility (APR-util) allows an attacker to write beyond bounds of a buffer. This issue affects Apache Portable Runtime Utility (APR-util) 1.6.1 and prior versions. Reference: https://nvd.nist.gov/vuln/detail/CVE-2022-25147<https://urldefense.com/v3/__https:/nvd.nist.gov/vuln/detail/CVE-2022-25147__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XH58ssc0$> It might make more sense to upgrade to 1.6.3, as it appears to include some additional fixes and no new features. https://downloads.apache.org/apr/CHANGES-APR-UTIL-1.6<https://urldefense.com/v3/__https:/downloads.apache.org/apr/CHANGES-APR-UTIL-1.6__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XNKeh7pM$> Signed-off-by: Narpat Mali <narpat.m...@windriver.com<mailto:narpat.m...@windriver.com>> --- .../apr/apr-util/CVE-2022-25147.patch | 180 ++++++++++++++++++ meta/recipes-support/apr/apr-util_1.6.1.bb<https://urldefense.com/v3/__http:/apr-util_1.6.1.bb__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XIvEEi5T$> | 3 +- 2 files changed, 182 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/apr/apr-util/CVE-2022-25147.patch diff --git a/meta/recipes-support/apr/apr-util/CVE-2022-25147.patch b/meta/recipes-support/apr/apr-util/CVE-2022-25147.patch new file mode 100644 index 0000000000..e85785aca0 --- /dev/null +++ b/meta/recipes-support/apr/apr-util/CVE-2022-25147.patch @@ -0,0 +1,180 @@ +From 3f5257075c7eb601aed6333e9bb5d9eb0e11254b Mon Sep 17 00:00:00 2001 +From: Yann Ylavic <yla...@apache.org<mailto:yla...@apache.org>> +Date: Thu, 20 Oct 2022 09:38:34 +0000 +Subject: [PATCH] apr_base64: Make sure encoding/decoding lengths fit in an int + >= 0. + +The (old) API of apr_base64 functions has always used int for representing +lengths and it does not return errors. Make sure to abort() if the provided +data don't fit. + +* encoding/apr_base64.c(): + #define APR_BASE64_ENCODE_MAX and APR_BASE64_DECODE_MAX as the hard length + limits for encoding and decoding respectively. + +* encoding/apr_base64.c(apr_base64_encode_len, apr_base64_encode, + apr_base64_encode_binary, apr_pbase64_encode): + abort() if the given length is above APR_BASE64_ENCODE_MAX. + +* encoding/apr_base64.c(apr_base64_decode_len, apr_base64_decode, + apr_base64_decode_binary, apr_pbase64_decode): + abort() if the given plain buffer length is above APR_BASE64_DECODE_MAX. + + +apr_base64: Follow up to r1902206: Cap to APR_BASE64_ENCODE_MAX in apr_pbase64_encode(). + + +Merges r1902206[, r1904666] from trunk. +Merges r1904727 from 1.7.x. + + +git-svn-id: https://svn.apache.org/repos/asf/apr/apr-util/branches/1.6.x@1904728<https://urldefense.com/v3/__https:/svn.apache.org/repos/asf/apr/apr-util/branches/1.6.x@1904728__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XIcUV_A5$> 13f79535-47bb-0310-9956-ffa450edef68 + +CVE: CVE-2022-25147 + +Upstream-Status: Backport [https://github.com/apache/apr-util/commit/3f5257075c7eb601aed6333e9bb5d9eb0e11254b<https://urldefense.com/v3/__https:/github.com/apache/apr-util/commit/3f5257075c7eb601aed6333e9bb5d9eb0e11254b__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XFWd2o7a$>] + +Signed-off-by: Narpat Mali <narpat.m...@windriver.com<mailto:narpat.m...@windriver.com>> +--- + encoding/apr_base64.c | 41 +++++++++++++++++++++++++---------------- + 1 file changed, 25 insertions(+), 16 deletions(-) + +diff --git a/encoding/apr_base64.c b/encoding/apr_base64.c +index e9b75e3d..ac9f2816 100644 +--- a/encoding/apr_base64.c ++++ b/encoding/apr_base64.c +@@ -20,11 +20,20 @@ + * ugly 'len' functions, which is quite a nasty cost. + */ + ++#undef NDEBUG /* always abort() on assert()ion failure */ ++#include <assert.h> ++ + #include "apr_base64.h" + #if APR_CHARSET_EBCDIC + #include "apr_xlate.h" + #endif /* APR_CHARSET_EBCDIC */ + ++/* Above APR_BASE64_ENCODE_MAX length the encoding can't fit in an int >= 0 */ ++#define APR_BASE64_ENCODE_MAX 1610612733 ++ ++/* Above APR_BASE64_DECODE_MAX length the decoding can't fit in an int >= 0 */ ++#define APR_BASE64_DECODE_MAX 2863311524u ++ + /* aaaack but it's fast and const should make it shared text page. */ + static const unsigned char pr2six[256] = + { +@@ -109,24 +118,22 @@ APU_DECLARE(apr_status_t) apr_base64init_ebcdic(apr_xlate_t *to_ascii, + + APU_DECLARE(int) apr_base64_decode_len(const char *bufcoded) + { +- int nbytesdecoded; + register const unsigned char *bufin; + register apr_size_t nprbytes; + + bufin = (const unsigned char *) bufcoded; + while (pr2six[*(bufin++)] <= 63); +- + nprbytes = (bufin - (const unsigned char *) bufcoded) - 1; +- nbytesdecoded = (((int)nprbytes + 3) / 4) * 3; ++ assert(nprbytes <= APR_BASE64_DECODE_MAX); + +- return nbytesdecoded + 1; ++ return (int)(((nprbytes + 3u) / 4u) * 3u + 1u); + } + + APU_DECLARE(int) apr_base64_decode(char *bufplain, const char *bufcoded) + { + #if APR_CHARSET_EBCDIC + apr_size_t inbytes_left, outbytes_left; +-#endif /* APR_CHARSET_EBCDIC */ ++#endif /* APR_CHARSET_EBCDIC */ + int len; + + len = apr_base64_decode_binary((unsigned char *) bufplain, bufcoded); +@@ -143,7 +150,7 @@ APU_DECLARE(int) apr_base64_decode(char *bufplain, const char *bufcoded) + * the conversion of the output to ebcdic is left out. + */ + APU_DECLARE(int) apr_base64_decode_binary(unsigned char *bufplain, +- const char *bufcoded) ++ const char *bufcoded) + { + int nbytesdecoded; + register const unsigned char *bufin; +@@ -153,12 +160,13 @@ APU_DECLARE(int) apr_base64_decode_binary(unsigned char *bufplain, + bufin = (const unsigned char *) bufcoded; + while (pr2six[*(bufin++)] <= 63); + nprbytes = (bufin - (const unsigned char *) bufcoded) - 1; +- nbytesdecoded = (((int)nprbytes + 3) / 4) * 3; ++ assert(nprbytes <= APR_BASE64_DECODE_MAX); ++ nbytesdecoded = (int)(((nprbytes + 3u) / 4u) * 3u); + + bufout = (unsigned char *) bufplain; + bufin = (const unsigned char *) bufcoded; + +- while (nprbytes > 4) { ++ while (nprbytes >= 4) { + *(bufout++) = + (unsigned char) (pr2six[*bufin] << 2 | pr2six[bufin[1]] >> 4); + *(bufout++) = +@@ -178,13 +186,8 @@ APU_DECLARE(int) apr_base64_decode_binary(unsigned char *bufplain, + *(bufout++) = + (unsigned char) (pr2six[bufin[1]] << 4 | pr2six[bufin[2]] >> 2); + } +- if (nprbytes > 3) { +- *(bufout++) = +- (unsigned char) (pr2six[bufin[2]] << 6 | pr2six[bufin[3]]); +- } + +- nbytesdecoded -= (4 - (int)nprbytes) & 3; +- return nbytesdecoded; ++ return nbytesdecoded - (int)((4u - nprbytes) & 3u); + } + + static const char basis_64[] = +@@ -192,6 +195,8 @@ static const char basis_64[] = + + APU_DECLARE(int) apr_base64_encode_len(int len) + { ++ assert(len >= 0 && len <= APR_BASE64_ENCODE_MAX); ++ + return ((len + 2) / 3 * 4) + 1; + } + +@@ -203,6 +208,8 @@ APU_DECLARE(int) apr_base64_encode(char *encoded, const char *string, int len) + int i; + char *p; + ++ assert(len >= 0 && len <= APR_BASE64_ENCODE_MAX); ++ + p = encoded; + for (i = 0; i < len - 2; i += 3) { + *p++ = basis_64[(os_toascii[string[i]] >> 2) & 0x3F]; +@@ -227,7 +234,7 @@ APU_DECLARE(int) apr_base64_encode(char *encoded, const char *string, int len) + } + + *p++ = '\0'; +- return p - encoded; ++ return (unsigned int)(p - encoded); + #endif /* APR_CHARSET_EBCDIC */ + } + +@@ -240,6 +247,8 @@ APU_DECLARE(int) apr_base64_encode_binary(char *encoded, + int i; + char *p; + ++ assert(len >= 0 && len <= APR_BASE64_ENCODE_MAX); ++ + p = encoded; + for (i = 0; i < len - 2; i += 3) { + *p++ = basis_64[(string[i] >> 2) & 0x3F]; +@@ -264,5 +273,5 @@ APU_DECLARE(int) apr_base64_encode_binary(char *encoded, + } + + *p++ = '\0'; +- return (int)(p - encoded); ++ return (unsigned int)(p - encoded); + } +-- +2.32.0 + diff --git a/meta/recipes-support/apr/apr-util_1.6.1.bb<https://urldefense.com/v3/__http:/apr-util_1.6.1.bb__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XIvEEi5T$> b/meta/recipes-support/apr/apr-util_1.6.1.bb<https://urldefense.com/v3/__http:/apr-util_1.6.1.bb__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XIvEEi5T$> index b851d46351..f5a2888016 100644 --- a/meta/recipes-support/apr/apr-util_1.6.1.bb<https://urldefense.com/v3/__http:/apr-util_1.6.1.bb__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XIvEEi5T$> +++ b/meta/recipes-support/apr/apr-util_1.6.1.bb<https://urldefense.com/v3/__http:/apr-util_1.6.1.bb__;!!AjveYdw8EvQ!esmjxUfJK-k9hsO2YirQJFIQnxsXzCV4RtEx_M__yeayUk40QbNFQWJtPzT-sS5xElVB-xSOU2N6XIvEEi5T$> @@ -14,7 +14,8 @@ SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.gz \ file://configure_fixes.patch \ file://run-ptest \ file://0001-Fix-error-handling-in-gdbm.patch \ -" + file://CVE-2022-25147.patch \ + " SRC_URI[md5sum] = "bd502b9a8670a8012c4d90c31a84955f" SRC_URI[sha256sum] = "b65e40713da57d004123b6319828be7f1273fbc6490e145874ee1177e112c459" -- 2.34.1
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177560): https://lists.openembedded.org/g/openembedded-core/message/177560 Mute This Topic: https://lists.openembedded.org/mt/97108181/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
