In libcurl's base64 encode function, the output buffer is allocated as follows without any checks on insize: malloc( insize * 4 / 3 + 4 ) On systems with 32-bit addresses in userspace (e.g. x86, ARM, x32), the multiplication in the expression wraps around if insize is at least 1GB of data. If this happens, an undersized output buffer will be allocated, but the full result will be written, thus causing the memory behind the output buffer to be overwritten. If a username is set directly via `CURLOPT_USERNAME` (or curl's `-u, --user` option), this vulnerability can be triggered. The name has to be at least 512MB big in a 32bit system. Systems with 64 bit versions of the `size_t` type are not affected by this issue. External References: https://curl.haxx.se/docs/adv_20161102C.html
Created attachment 1213772 [details] Upstream patch
Created curl tracking bugs for this issue: Affects: fedora-all [bug 1390894]
Created mingw-curl tracking bugs for this issue: Affects: fedora-all [bug 1390895] Affects: epel-7 [bug 1390896]
This issue has been addressed in the following products: Red Hat JBoss Core Services Via RHSA-2018:2486 https://access.redhat.com/errata/RHSA-2018:2486
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Via RHSA-2018:3558 https://access.redhat.com/errata/RHSA-2018:3558