Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
Created attachment 37592
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37592&action=edit
Test Case #1
The attached program binary causes a buffer overflow in cplus-dem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #1 from Marcel Böhme ---
Created attachment 37593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37593&action=edit
Test Case #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #3 from Marcel Böhme ---
Hi Markus,
Indeed, it depends on the use case. I find it quite unsettling to know that
common digital forensics tools, such as gdb and objdump, are vulnerable to
execute arbitrary code.
How much credibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #4 from Marcel Böhme ---
Here is my preliminary analysis:
The function demangle_args (cplus-dem.c:4424) parses the (crafted) mangled
function args from the binary. In line 4452, r is read from mangled. In line
4491, we enter a loop wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #5 from Marcel Böhme ---
Created attachment 37612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37612&action=edit
Debug This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #7 from Marcel Böhme ---
Created attachment 37620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37620&action=edit
Valgrind This
$ cat compileme.c
#include
#include
const char*
X00020A___R0020A__U000R03000N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
Marcel Böhme changed:
What|Removed |Added
Severity|normal |major
--- Comment #8 from Marcel Böhme -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #9 from Marcel Böhme ---
Created attachment 37839
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37839&action=edit
Proposed Patch
* Limiting the length of the mangled string to 264k characters.
* Limiting the loop iterations to
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
In the most recent version, Valgrind reports an invalid write of size 8 due to
a use-after-free if the demangler is called with a certain class signature.
However, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70481
--- Comment #2 from Marcel Böhme ---
These are two distinct bugs. During fuzzing the btypevec bug appears more
often. But it seemed less critical since only NULL is written to the freed
memory:
work -> btypevec[ret] = NULL;
On the other hand, th
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
Valgrind reports an invalid write of size 8 due to an integer overflow in the
demangling of virtual tables in method gnu_special.
How to Reproduce:
$ valgrind c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70492
--- Comment #1 from Marcel Böhme ---
This error was found during fuzzing with a more efficient version of AFL.
Patch and reviews available here:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg0.html
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
Due to the inconsistent use of long and int for string/array length in
cp-demangle.c there is an integer overflow that leads to a write access
violation. The target crashes on an
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
A stack overflow in the libiberty demangler library causes its host
applications to crash. The stack contains return addresses that are not mapped
in the inferior's process ad
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
A write access violation on destination operand in the libiberty demangler
causes its host applications to crash. There are also two other read access
violations on source operand
Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
Dear all,
Passing "@." or "@" as argument causes gcc, gcov, and all of
binutils to fail after trying to allocate a large (but fixed) chunk of memory
(0x7F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584
--- Comment #7 from Marcel Böhme ---
My system parameters:
KERNEL VERSION: Ubuntu 14.04.3 LTS (GNU/Linux 3.19.0-59-generic x86_64)
GLIBC: Ubuntu EGLIBC 2.19-0ubuntu6.9
FILE SYSTEM: ext4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #18 from Marcel Böhme ---
(In reply to Markus Trippelsdorf from comment #17)
> Nathan's patch fixes this issue:
> https://patchwork.ozlabs.org/patch/701137/
> It is currently being reviewed.
It doesn't seem to fix the original issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #31 from Marcel Böhme ---
Hi Mark,
Your patch looks good to me. One more thing: It seems that our patches evaluate
these two mangled strings differently. Is it because of Nathan's patch? Can
these strings be demangled properly at all
++
Assignee: unassigned at gcc dot gnu.org
Reporter: boehme.marcel at gmail dot com
Target Milestone: ---
A stackoverflow in the libiberty demangler causes its host application to crash
on a tainted branch instruction. The problem is caused by a self-reference in a
mangled type string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #2 from Marcel Böhme ---
Here: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00105.html
Pending review.
21 matches
Mail list logo
