>
> 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 some
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 arbitr
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
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 func
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 wrote:
>
> On 03/03/
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 and using INT_MAX.
>
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 unreasonable limits! Wonderful.
>> Hope someon
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 approve.
Marcel, if you haven't
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 th
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.
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 constant… you can al
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
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
On Mar 2, 2016, at 12:33 AM, Marcel Böhme 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 the spirit of GNU software.
> * Limiting the loo
14 matches
Mail list logo
