Re: Fix fir PR71696 in Libiberty Demangler (6)

revision 239112) +++ libiberty/testsuite/demangle-expected (working copy) @@ -4587,3 +4587,8 @@ _Z808 __t2m05B50_ __t2m05B50_ +# +# Tests stack overflow PR71696 + +__10%0__S4_0T0T0 +%0<>::%0(%0<>) Index: libiberty/ChangeLog

Re: Fix fir PR71696 in Libiberty Demangler (6)

Hi, This patch is still pending a full review. Best regards, - Marcel > On 4 Jul 2016, at 8:54 PM, Bernd Schmidt <bschm...@redhat.com> wrote: > > On 06/30/2016 08:46 AM, Marcel Böhme wrote: >> The attached patch fixes the stack overflow in the demangler due to >&g

Re: Fix for PR70909 in Libiberty Demangler (4)

Hi, This patch is still pending a full review. Best regards, - Marcel > On 30 Jun 2016, at 12:09 AM, Pedro Alves <pal...@redhat.com> wrote: > > On 06/29/2016 08:43 AM, Marcel Böhme wrote: >> Hi Jason, >> >> These test cases are generated by fuzzing which

Fix fir PR71696 in Libiberty Demangler (6)

696 is resolved. Index: libiberty/ChangeLog === --- libiberty/ChangeLog (revision 237852) +++ libiberty/ChangeLog (working copy) @@ -1,3 +1,21 @@ +2016-06-30 Marcel Böhme <boehme.mar...@gmail.com> + + * cplus-dem.c: Prevent

Re: Fix for PR70909 in Libiberty Demangler (4)

:05 PM, Jason Merrill <ja...@redhat.com> wrote: > > It seems like in cases of malformed input we should return the input > again rather than produce garbage like "K> ". Maybe catch this sort of situation in > d_lookup_template_parameter? > > Jason > > >

Re: Fix for PR70926 in Libiberty Demangler (5)

Hi Jeff, On 23 Jun 2016, at 4:21 AM, Jeff Law wrote: > > OK for the trunk. Please install. > > Sorry for the delays. > > Jeff I might not have the access rights to commit to trunk. Best regards - Marcel

Re: Fix for PR70909 in Libiberty Demangler (4)

Hi, This patch is pending a careful review. Best regards, - Marcel > On 2 May 2016, at 11:21 PM, Marcel Böhme <boehme.mar...@gmail.com> wrote: > > Hi, > > This fixes several stack overflows due to infinite recursion in d_print_comp > (https://gcc.gnu.org/bugzil

Re: Fix for PR70926 in Libiberty Demangler (5)

Hi: Pending review. Best - Marcel > On 3 May 2016, at 10:40 PM, Marcel Böhme <boehme.mar...@gmail.com> wrote: > > Hi, > > This fixes four access violations > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70926). > > Two of these first read the value of a length

Re: Fix for PR68159 in Libiberty Demangler (6)

Hi Ian, Stack overflows are a security concern and must be addressed. The Libiberty demangler is part of several tools, including binutils, gdb, valgrind, and many other libbfd-based tools that are used by the security community for the analysis of program binaries. Without a patch, the

Re: Fix for PR68159 in Libiberty Demangler (6)

Hi, This patch also removes the following part of the comment for method cplus_demangle_print_callback: "It does not use heap memory to build an output string, so cannot encounter memory allocation failure”. > On 6 May 2016, at 11:11 PM, Marcel Böhme <boehme.mar...@gmail

Re: Fix for PR68159 in Libiberty Demangler (6)

ChangeLog (revision 235962) +++ libiberty/ChangeLog (working copy) @@ -1,3 +1,14 @@ +2016-05-06 Marcel Böhme <boehme.mar...@gmail.com> + + PR c++/68159 + * cp-demangle.c: Allocate arrays of user-defined size on the heap, + not on the stack. Do not include . + (CP

Re: Fix for PR68159 in Libiberty Demangler (6)

Log === --- libiberty/ChangeLog (revision 235962) +++ libiberty/ChangeLog (working copy) @@ -1,3 +1,14 @@ +2016-05-06 Marcel Böhme <boehme.mar...@gmail.com> + + PR c++/68159 + * cp-demangle.c: Allocate arrays o

Re: Fix for PR68159 in Libiberty Demangler (6)

there are more concerns. There might be some more formatting issues lingering. Best regards, - Marcel Index: ChangeLog === --- ChangeLog (revision 235941) +++ ChangeLog (working copy) @@ -1,3 +1,14 @@ +2016-05-06 Marcel Böhme

Fix for PR68159 in Libiberty Demangler (6)

regards, - Marcel Index: ChangeLog === --- ChangeLog (revision 235941) +++ ChangeLog (working copy) @@ -1,3 +1,14 @@ +2016-05-06 Marcel Böhme <boehme.mar...@gmail.com> + + PR c++/68159 + * cp-demangle.c:

Fix for PR70926 in Libiberty Demangler (5)

=== --- libiberty/ChangeLog (revision 235801) +++ libiberty/ChangeLog (working copy) @@ -1,3 +1,12 @@ +2016-05-03 Marcel Böhme <boehme.mar...@gmail.com> + + PR c++/70926 + * cplus-dem.c: Handle large values and overflow when dema

Fix for PR70909 in Libiberty Demangler (4)

@@ +2016-05-02 Marcel Böhme <boehme.mar...@gmail.com> + + PR c++/70909 + PR c++/61460 + PR c++/68700 + PR c++/67738 + PR c++/68383 + PR c++/70517 + PR c++/61805 + PR c++/62279 + PR c++/67264 + * cp-demangle.c: Prevent infinite recursio

Re: Fix for PR70498 in Libiberty Demangler

ngeLog (working copy) @@ -1,3 +1,22 @@ +2016-04-16 Marcel Böhme <boehme.mar...@gmail.com> + + PR c++/70498 + * cp-demangle.c: Parse numbers as integer instead of long to avoid + overflow after sanity checks. Include if available. + (INT_MAX)

Re: Fix for PR70498 in Libiberty Demangler

=== --- ChangeLog (revision 235032) +++ ChangeLog (working copy) @@ -1,3 +1,22 @@ +2016-04-16 Marcel Böhme <boehme.mar...@gmail.com> + + PR c++/70498 + * cp-demangle.c: Parse/handle numbers as integer instead of long. + Include if available. + (INT_MAX): Define if n

Re: Fix for PR70498 in Libiberty Demangler

Hi Bernd, > -static long > +static int > d_compact_number (struct d_info *di) > { > - long num; > + int num; >if (d_peek_char (di) == '_') > num = 0; >else if (d_peek_char (di) == 'n') > @@ -2957,7 +2957,7 @@ d_compact_number (struct d_info *di) >else > num = d_number

Re: Fix for PR70498 in Libiberty Demangler

> On 4 Apr 2016, at 9:24 PM, Bernd Schmidt wrote: > >> >> The patch now also accounts for overflows in d_compact_number which >> is supposed to return -1 in case of negative numbers. > > I take it this isn't for the normal 'n' case, but for instances where we > encounter

Re: Fix for PR70498 in Libiberty Demangler

> On 2 Apr 2016, at 1:44 AM, Bernd Schmidt <bschm...@redhat.com> wrote: > > On 04/01/2016 07:41 PM, Pedro Alves wrote: >> On 04/01/2016 11:21 AM, Marcel Böhme wrote: >>> static inline void >>> -d_append_num (struct d_print_info *dpi, long l) >>>

Re: Proposed Patch for Bug 69687

> > 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: Fix for PR70498 in Libiberty Demangler

> Since d_identifier takes an int as length, d_identifier is called with a > negative length after the implicit cast: Sorry, d_make_name called from d_identifier in cp_demangle.c:1721 takes an int as length. Best regards - Marcel

Re: Fix for PR70498 in Libiberty Demangler

Hi Bernd, Thanks for the feedback! > Patches need to be bootstrapped and regression tested, and patch submissions > should include which target this was done on. > > Ideally you'd also want to include testcases along with your patches, > although I'm not entirely sure how we can arrange for

Fix for PR70498 in Libiberty Demangler

Hi, This fixes the write access violation detailed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498 (and a few other unreported cases). Sometimes length-variables for strings and arrays are of type long other times of type int. Since cp-demangle.h exports structs and methods with

Fix for PR70492

Hi, This fixes the invalid write of size 8 detailed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70492 Handle the special case when consume_count returns -1 due to an integer overflow when parsing the length of the virtual table qualifier in cplus-dem.c:2994 (gnu_special). Index:

Fix for PR70481 Libiberty Demangler

Hi, This fixes the use-after-free detailed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70481 There is a variable ksize storing the amount of allocated memory for the array ktypevec. ksize being zero (0) indicates that some memory must be allocated upon the first write. When more memory is

Re: Proposed Patch for Bug 69687

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

at.com> wrote: > > On 03/03/2016 04:18 PM, Mike Stump wrote: >> On Mar 3, 2016, at 6:55 AM, Marcel Böhme <boehme.mar...@gmail.com> wrote: >>> I have revised the patch and removed the limits. >> >> I looked at the patch, I can find no more unreasonable limit

Re: Proposed Patch for Bug 69687

On 4 Mar 2016, at 1:43 AM, Bernd Schmidt <bschm...@redhat.com> wrote: > > On 03/03/2016 04:18 PM, Mike Stump wrote: >> On Mar 3, 2016, at 6:55 AM, Marcel Böhme <boehme.mar...@gmail.com> wrote: >>> I have revised the patch and removed the limits. >> >&

Re: Proposed Patch for Bug 69687

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

Proposed Patch for Bug 69687

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 +++