From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 85CF0383300A; Mon, 30 Nov 2020 11:02:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 85CF0383300A From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug remote/26614] AddressSanitizer: heap-use-after-free of extended_remote_target in remote_async_inferior_event_handler Date: Mon, 30 Nov 2020 11:02:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: remote X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 11:02:42 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26614 --- Comment #15 from Tom de Vries --- (In reply to Simon Marchi from comment #13) > If that's indeed the problem, I can see two solutions: >=20 > 1. Have some kind of listener that the function can install locally to get > notified if the target gets destroyed, and skip the following code if so. OK, I see how that would work. > 2. That code exists to re-mark the async event handler if we still have > things to report, because it is automatically cleared by > check_async_event_handlers. Instead, we can make check_async_event_handl= ers > leave the async event handler marked and let the target clear it in its > ::wait implementation when it no longer has anything to report. Or, as a > stop-gap solution, have the remote_async_inferior_event_handler re-mark t= he > handler before calling inferior_event_handler and clear it in ::wait if > there's nothing else to report. >=20 > I have a patch that does that (in the middle of a big work-in-progress > series), as you can see it gets rid of the problematic code: >=20 > https://review.lttng.org/c/binutils-gdb/+/4050/11 I've looked at this briefly, but unfortunately I'm unfamiliar with this cod= e, so I'm not able to comment. FWIW, I wrote an adhoc patch to test my understanding of the problem. It indeed fixes the ERRORs triggered by the trigger patch: ... diff --git a/gdb/async-event.c b/gdb/async-event.c index ffc0edcde8..702b434365 100644 --- a/gdb/async-event.c +++ b/gdb/async-event.c @@ -327,3 +327,18 @@ delete_async_event_handler xfree (*async_handler_ptr); *async_handler_ptr =3D NULL; } + +extern bool has_async_event_handler (gdb_client_data data); + +bool +has_async_event_handler (gdb_client_data data) +{ + async_event_handler *ptr; + for (ptr =3D async_event_handler_list.first_handler; + ptr !=3D NULL; + ptr =3D ptr->next_handler) + if (ptr->client_data =3D=3D data) + return true; + + return false; +} diff --git a/gdb/remote.c b/gdb/remote.c index 59075cb09f..8e42c32249 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -14155,15 +14155,19 @@=20 static void remote_async_inferior_event_handler (gdb_client_data data) { + extern bool has_async_event_handler (gdb_client_data data); + gdb_assert (has_async_event_handler (data)); inferior_event_handler (INF_REG_EVENT); + if (!has_async_event_handler (data)) + return; remote_target *remote =3D (remote_target *) data; remote_state *rs =3D remote->get_remote_state (); ... and indeed that works. AFAIU, this patch is not good enough because it tests for equality with a pointer to a deleted object. --=20 You are receiving this mail because: You are on the CC list for the bug.=