From: Nick Clifton <nickc@redhat.com>
To: Cary Coutant <ccoutant@gmail.com>,
Jakub Jelinek <jakub@redhat.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Binutils <binutils@sourceware.org>,
sgayou@redhat.com, Jason Merrill <jason@redhat.com>,
Michael Matz <matz@suse.de>
Subject: Re: RFA/RFC: Add stack recursion limit to libiberty's demangler
Date: Mon, 03 Dec 2018 14:53:00 -0000 [thread overview]
Message-ID: <e1e1fec8-a458-d30c-c37b-bf1dba840419@redhat.com> (raw)
In-Reply-To: <CAJimCsES7ctTGHWRDHAdEEiwiY3nWCod5xdo4MSSAGDCmk53qg@mail.gmail.com>
Hi Cary,
> In order to handle arbitrary user input without crashing, perhaps the
> demangler should switch from recursive descent parsing to a state
> machine, where exhaustion of resources can be handled gracefully.
I think that that would be a better long term fix for the problem,
but it is not one that I have time to work on right now.
My main goal with this patch submission is to stop the flood of PR
and CVEs about mangled inputs that trigger stack exhaustion. Being
able to properly demangle such inputs would be nice, but not something
that I think should be a priority. I think that in real life no
program is ever going to generate a mangled name that is sufficiently
complex to trigger a seg-fault this way, so the only real purpose of
the patch is to resolve these PRs and stop more from being filed.
Cheers
Nick
next prev parent reply other threads:[~2018-12-03 14:53 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 8:38 Nick Clifton
2018-11-30 8:42 ` Jakub Jelinek
2018-11-30 10:27 ` Nick Clifton
2018-11-30 13:46 ` Michael Matz
2018-11-30 14:57 ` Ian Lance Taylor
2018-12-02 0:49 ` Cary Coutant
2018-12-03 14:53 ` Nick Clifton [this message]
2018-12-03 22:00 ` Joseph Myers
2018-11-30 13:56 ` Ian Lance Taylor
2018-11-30 14:03 ` Jakub Jelinek
2018-11-30 17:41 ` RFA/RFC: Add stack recursion limit to libiberty's demangler [v3] Nick Clifton
2018-11-30 17:49 ` Jakub Jelinek
2018-11-30 18:19 ` Pedro Alves
2018-12-03 10:28 ` Richard Biener
2018-12-03 14:45 ` Nick Clifton
2018-12-03 18:49 ` Ian Lance Taylor via gcc-patches
2018-12-04 14:00 ` RFA/RFC: Add stack recursion limit to libiberty's demangler [v4] Nick Clifton
2018-12-04 15:02 ` Pedro Alves
2018-12-04 16:57 ` RFA/RFC: Add stack recursion limit to libiberty's demangler [v5] Nick Clifton
2018-12-04 17:08 ` Pedro Alves
2018-12-06 11:12 ` Nick Clifton
2018-12-06 18:04 ` Ian Lance Taylor via gcc-patches
2018-12-07 16:17 ` H.J. Lu
2018-12-07 16:25 ` [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536 H.J. Lu
2018-12-10 14:52 ` Michael Matz
2018-12-10 15:10 ` Jakub Jelinek
2018-12-10 15:34 ` Jason Merrill
2018-12-11 0:33 ` Jeff Law
2018-12-11 6:58 ` Jakub Jelinek
2018-12-11 11:05 ` Pedro Alves
2018-12-11 14:26 ` Ian Lance Taylor via gcc-patches
2018-12-11 15:07 ` Pedro Alves
2018-12-11 10:34 ` Pedro Alves
2018-12-10 15:12 ` Nick Clifton
2018-12-10 15:18 ` Jakub Jelinek
2018-12-10 15:26 ` Nick Clifton
2018-12-10 15:35 ` Jakub Jelinek
2018-12-10 18:20 ` Ian Lance Taylor via gcc-patches
2018-12-10 18:55 ` Jakub Jelinek
2018-12-10 23:47 ` Jason Merrill
2018-12-10 15:18 ` David Malcolm
2018-12-10 15:31 ` Nick Clifton
2018-12-06 16:14 ` RFA/RFC: Add stack recursion limit to libiberty's demangler [v5] Jason Merrill
2018-12-06 21:22 ` RFC: libiberty PATCH to disable demangling of ancient mangling schemes Jason Merrill
2018-12-07 10:27 ` Nick Clifton
2018-12-07 10:40 ` Jakub Jelinek
2018-12-07 16:11 ` Pedro Alves
2018-12-07 17:49 ` Tom Tromey
2018-12-07 21:00 ` Jason Merrill
2018-12-14 22:39 ` Jason Merrill
2018-12-16 4:50 ` Simon Marchi
2018-12-07 16:28 ` Nick Clifton
2018-12-07 11:37 ` Richard Biener
2018-12-07 15:49 ` Jason Merrill
2018-12-10 1:04 ` Eric Gallager
-- strict thread matches above, loose matches on Subject: below --
2018-11-29 15:01 RFA/RFC: Add stack recursion limit to libiberty's demangler Nick Clifton
2018-11-29 17:08 ` Scott Gayou
2018-11-30 8:42 ` Nick Clifton
2018-11-29 18:20 ` Pedro Alves
2018-11-29 22:18 ` Ian Lance Taylor
[not found] ` <87h8fza6fh.fsf@tromey.com>
[not found] ` <43e6c9e6-8249-bf56-aed8-90d0f771c567@redhat.com>
2018-11-30 11:58 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1e1fec8-a458-d30c-c37b-bf1dba840419@redhat.com \
--to=nickc@redhat.com \
--cc=binutils@sourceware.org \
--cc=ccoutant@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jason@redhat.com \
--cc=matz@suse.de \
--cc=sgayou@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).