Date: Wed, 04 Feb 2015 10:42:41 +0100 From: Florian Weimer <fweimer@...hat.com> To: oss-security@...ts.openwall.com CC: cve-assign@...re.org, jsm28@....gnu.org Subject: Re: Re: CVE request: heap buffer overflow in glibc swscanf On 02/04/2015 04:16 AM, cve-assign@...re.org wrote: >> 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. If you want to assign CVE IDs for stack overflows in glibc without demonstrated application impact, we really need to find a way to streamline the process because there are quite a few missing assignments. I wouldn't mind getting a pool of CVEs (for multiple years, going back to around 2000), and assigning them to issues in the glibc Bugzilla instance, and posting weekly summaries to oss-security. Would that work for you? -- Florian Weimer / Red Hat Product Security
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ