Re: Proposed Patch for Bug 69687

2016-04-01 Thread Marcel Böhme
> > Forgot about this issue, sorry. At least this needs guarding with #ifdef > HAVE_LIMITS_H, as in the other files in libiberty. Several of them also go to > trouble to define the macros if limits.h is missing; not sure how much of an > issue that is nowadays, but you might want to adapt

Re: Proposed Patch for Bug 69687

2016-04-01 Thread Bernd Schmidt
On 03/31/2016 06:56 AM, Marcel Böhme wrote: Hi Bernd, Are all the places being patched really problematic ones where an input file could realistically cause an overflow, or just the string functions? The loop in demangle_args allows to call the patched register*- and remember*-methods

Re: Proposed Patch for Bug 69687

2016-03-30 Thread Marcel Böhme
Hi Bernd, > Are all the places being patched really problematic ones where an input file > could realistically cause an overflow, or just the string functions? The loop in demangle_args allows to call the patched register*- and remember*-methods arbitrarily often. So, those should also overflow

Re: Proposed Patch for Bug 69687

2016-03-29 Thread Bernd Schmidt
On 03/03/2016 03:55 PM, Marcel Böhme wrote: @@ -4254,7 +4255,9 @@ Please use "diff -p" so that we get information about which function is being patched. Are all the places being patched really problematic ones where an input file could realistically cause an overflow, or just the string

Re: Proposed Patch for Bug 69687

2016-03-28 Thread Marcel Böhme
Hi Bernd: I submitted the filled disclaimer form on March 4th. Now, a representative of FSF mentioned that the copyright assignment is ready on their end. Can someone please go ahead and review the patch? Best regards, - Marcel > On 4 Mar 2016, at 1:43 AM, Bernd Schmidt

Re: Proposed Patch for Bug 69687

2016-03-04 Thread Joseph Myers
On Thu, 3 Mar 2016, Mike Stump wrote: > On Mar 3, 2016, at 6:21 AM, Bernd Schmidt wrote: > > What C standard can we assume for libiberty? I was looking at patching this > > and discovered that SIZE_MAX is defined only for C99, so I'm leaning > > towards retaining the ints

Re: Proposed Patch for Bug 69687

2016-03-03 Thread Marcel Böhme
On 4 Mar 2016, at 1:43 AM, Bernd Schmidt wrote: > > On 03/03/2016 04:18 PM, Mike Stump wrote: >> On Mar 3, 2016, at 6:55 AM, Marcel Böhme wrote: >>> I have revised the patch and removed the limits. >> >> I looked at the patch, I can find no more

Re: Proposed Patch for Bug 69687

2016-03-03 Thread Bernd Schmidt
On 03/03/2016 04:18 PM, Mike Stump wrote: On Mar 3, 2016, at 6:55 AM, Marcel Böhme wrote: I have revised the patch and removed the limits. I looked at the patch, I can find no more unreasonable limits! Wonderful. Hope someone will finish off the review and

Re: Proposed Patch for Bug 69687

2016-03-03 Thread Manuel López-Ibáñez
On 03/03/16 14:21, Bernd Schmidt wrote: On 03/02/2016 06:22 PM, Mike Stump wrote: So, check for overflow, or better use unsigned values that are large enough to never overflow. With no possibility for overflow, you can then retest the bug and see if there are any other failure modes and fix

Re: Proposed Patch for Bug 69687

2016-03-03 Thread Mike Stump
On Mar 3, 2016, at 6:55 AM, Marcel Böhme wrote: > I have revised the patch and removed the limits. I looked at the patch, I can find no more unreasonable limits! Wonderful. Hope someone will finish off the review and approve.

Re: Proposed Patch for Bug 69687

2016-03-03 Thread Mike Stump
On Mar 3, 2016, at 6:21 AM, Bernd Schmidt wrote: > What C standard can we assume for libiberty? I was looking at patching this > and discovered that SIZE_MAX is defined only for C99, so I'm leaning towards > retaining the ints and using INT_MAX. As long as you don’t need a

Re: Proposed Patch for Bug 69687

2016-03-03 Thread Marcel Böhme
Thanks Mike. I have revised the patch and removed the limits. While perhaps less security critical, without the limits on the loop count (r) the test cases will still consume all your memory and effectively freeze GDB. * Before any realloc, check for overflow. * string_need now returns 1 if the

Re: Proposed Patch for Bug 69687

2016-03-03 Thread Bernd Schmidt
On 03/02/2016 06:22 PM, Mike Stump wrote: So, check for overflow, or better use unsigned values that are large enough to never overflow. With no possibility for overflow, you can then retest the bug and see if there are any other failure modes and fix those. What C standard can we assume for

Re: Proposed Patch for Bug 69687

2016-03-02 Thread Mike Stump
On Mar 2, 2016, at 12:33 AM, Marcel Böhme <boehme.mar...@gmail.com> wrote: > Please find attached the proposed patch for Bug 69687: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 > > * Limiting the length of the mangled string to 264k characters. No. This isn’t in

Proposed Patch for Bug 69687

2016-03-02 Thread Marcel Böhme
Hi, Please find attached the proposed patch for Bug 69687: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 * Limiting the length of the mangled string to 264k characters. * Limiting the loop iterations to 256 (max. of C++ function parameters). --- a/libiberty/cplus-dem.c +++ b/libiberty