Bug 28718 - debug.c: Stack-overflow in debug_write_type
Summary: debug.c: Stack-overflow in debug_write_type
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.38
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-20 19:22 UTC by Pavel Mayorov
Modified: 2022-01-07 12:37 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
PoC and ASAN report (1.27 KB, application/x-zip-compressed)
2021-12-20 19:22 UTC, Pavel Mayorov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Mayorov 2021-12-20 19:22:50 UTC
Created attachment 13870 [details]
PoC and ASAN report

I found a stack-overflow in 'debug_write_type' (binutils/debug.c). The problem is caused by a self-reference in a type definition string in the "stabs" representation of debugging information (http://www.sourceware.org/gdb/onlinedocs/stabs.html). 
This leads to an infinite recursion during the printing debug information about this type.

There is the following type definition:
    .stabs "some_type:t&1=2=3=2",128,0,0,0
Here 'some_type' is defined as a reference to the indirect type 1, which is the indirect type 2, which is the indirect type 3, which finally is the indirect type 2. And after parsing we get a "looped" type 2:
    *type->u.kindirect->slot == type

Steps to reproduce:

Build current verison of binutils with ASAN:
./configure --disable-shared --disable-gdb --disable-gdbserver CFLAGS="-ggdb -Wno-error -fsanitize=address -fsanitize-recover=address" CXXFLAGS="-ggdb -Wno-error -fsanitize=address -fsanitize-recover=address"
make all

Run inputs under ASAN:
binutils/objdump -g ~/stack_overflow

The proof-of-concept and ASAN report are attached.

And I'm preparing a patch to solve this issue.
Comment 1 Sourceware Commits 2022-01-06 16:38:01 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=af4004d1da135610ab931e04a3ba2c9124defbd7

commit af4004d1da135610ab931e04a3ba2c9124defbd7
Author: Nick Clifton <nickc@redhat.com>
Date:   Thu Jan 6 16:37:26 2022 +0000

    Fix a stack exhaustion bug parsing malicious STABS format debug information.
    
            PR 28718
            * debug.c (debug_write_type): Allow for malicious recursion via
            indirect debug types.
Comment 2 Nick Clifton 2022-01-06 16:40:13 UTC
Hi Pavel,

  Thanks for reporting this problem.

  I know that you are working on a fix, but I wanted to make sure that the issue was resolved before the 2.38 branch happens, so I have gone ahead and applied a patch of my own.  If you wish to submit your patch for review however, please do so.

Cheers
  Nick
Comment 3 Pavel Mayorov 2022-01-06 21:32:49 UTC
Hi Nick.
I submitted the patch for review the same day (https://sourceware.org/pipermail/binutils/2021-December/118976.html)... but still haven't received any response.

Best regards,
Pavel
Comment 4 Sourceware Commits 2022-01-07 12:35:29 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0e9f1c04b9572920c7f940203a67d5af3f6c19f6

commit 0e9f1c04b9572920c7f940203a67d5af3f6c19f6
Author: Pavel Mayorov <pmayorov@cloudlinux.com>
Date:   Fri Jan 7 12:34:37 2022 +0000

    Revert previous delta to debug.c.  Replace with patch to reject indirect types that point to indirect types.
    
            PR 28718
            * dwarf.c: Revert previous delta.
            (debug_get_real_type): Reject indirect types that point to
            indirect types.
            (debug_get_type_name, debug_get_type_size, debug_write_type):
            Likewise.
Comment 5 Nick Clifton 2022-01-07 12:37:21 UTC
(In reply to Pavel Mayorov from comment #3)
> I submitted the patch for review the same day
> (https://sourceware.org/pipermail/binutils/2021-December/118976.html)... but
> still haven't received any response.

Well I apologise for that.  I must have missed it.

I looked over your patch, and it is a much better solution than the one that I had designed, so I have gone ahead and reverted my patch and applied yours instead.

Cheers
  Nick