aboutsummaryrefslogtreecommitdiff
path: root/gold/Makefile.in
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2021-12-02 11:05:17 +0000
committerAndrew Burgess <aburgess@redhat.com>2021-12-03 09:54:44 +0000
commit7a34f66b23d459d81315a4f7e63549eaa2f9cf51 (patch)
treed5460ae37ecc0d939d082807e7b0816659635821 /gold/Makefile.in
parentba4ba9711a1356909275196c2abfd33f7d0950a6 (diff)
downloadgdb-7a34f66b23d459d81315a4f7e63549eaa2f9cf51.zip
gdb-7a34f66b23d459d81315a4f7e63549eaa2f9cf51.tar.gz
gdb-7a34f66b23d459d81315a4f7e63549eaa2f9cf51.tar.bz2
gdb/remote: fix use after free bug
This commit: commit 288712bbaca36bff6578bc839ebcdc3707662f81 Date: Mon Nov 22 15:16:27 2021 +0000 gdb/remote: use scoped_restore to control starting_up flag introduced a use after free bug. The scoped restore added in the above commit resets a flag within a remote_target's remote_state object. However, in some situations, the remote_target can be unpushed before the error is thrown. If the only reference to the target is the one in the target stack, then unpushing the target will cause the remote_target to be deleted, which, in turn, will delete the remote_state object. The scoped restore will then try to reset the flag within a deleted object. This problem was caught in the gdb.server/server-connect.exp test, which, when run with the address sanitizer enabled, highlights the write after free bug described above. This commit resolves this issue by adding a new class specifically for the purpose of managing the starting_up flag. As well as setting, and then clearing the starting_up flag, this new class increments, and then decrements the reference count on the remote_target object. This prevents the remote_target from being deleted until after the flag has been reset. The gdb.server/server-connect.exp now runs cleanly with the address sanitizer enabled.
Diffstat (limited to 'gold/Makefile.in')
0 files changed, 0 insertions, 0 deletions