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.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.