Date: Tue, 3 Feb 2015 22:16:41 -0500 (EST) From: cve-assign@...re.org To: ppluzhnikov@...il.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, jsm28@....gnu.org Subject: Re: CVE request: heap buffer overflow in glibc swscanf -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > https://sourceware.org/bugzilla/show_bug.cgi?id=16618 > stdio-common/vfscanf.c has an ADDW macro that tries to determine > whether to use malloc or alloca for allocations. But in the malloc > case, it only allocates newsize bytes instead of the required > newsize * sizeof (CHAR_T). Thus the allocated buffer gets overrun in > the wide-string case ( referring to https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob_plain;f=stdio-common/vfscanf.c;hb=HEAD ) Use CVE-2015-1472 for this issue in which an incorrect second argument to realloc leads to a buffer overflow. > The logic also has a problem that the comparison UCHAR_MAX + 1 > > 2 * wpmax doesn't allow for 2 * wpmax overflowing, though that would > only apply if half the address space gets allocated. We think you mean that the integer overflow isn't reachable because, on platforms supported by glibc, the ADDW macro wouldn't be used in a case where "2 * wpmax" overflows. The value of wpmax is limited by the requirement that that value was previously used in a successful realloc call. If the realloc had failed, a "goto errout" would have occurred. If this is incorrect and the integer overflow actually is reachable when operating on very long input data, then a separate CVE ID can be assigned for the integer overflow. In any case, the integer overflow is not within the scope of CVE-2015-1472. > The check with __libc_use_alloca also checks against the number of > array entries to allocate rather than the number of bytes, so the > function can allocate up to four times as many bytes as is libc policy > on the stack in the wide character case. Here, it seems that the goal of the policy is risk management for use of alloca. This is security relevant for some applications that use glibc, because it could (for example) allow a denial of service attack that's intended to trigger a failed alloca. There was one intended policy, and the the incorrect "__libc_use_alloca (newsize)" caused a different (and weaker) policy to be enforced instead. Use CVE-2015-1473 for this risk-management error. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJU0Y4mAAoJEKllVAevmvmsgBUIAMj4u37bJEH/oibsqjXHcSgz C1XY1mZej/ojdVuAmWyiX1MZGUDzhaLEz6AdRjhQg7BtdVUfdQ1PjV8q+PT8gORD nuIwWYT281XbIuVkJ2YT2Su789FxylQeOYhzl2rDyKecc+J24v/eL7PNFNrcYy2+ 1/i+q2FXFS0lP6QcvZbWlEryJzWl4sN47LIwvhreRsWFH5N4o7x6It7mzE3yRu5O YAb52wRPABFWDozyYgDc06qood/Gyok1eCBzkhuO7MRO4dAjWexPh2oEg7mFkygM 6FM/P6wNbN/n5Hqx39+PE/TQCKVuWZFcrATFugFiWSVWPBlEQjJpcctJv2TNQC8= =lBV+ -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.