From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: "Edgar E . Iglesias" <edgar.iglesias@xilinx.com>,
Peter Maydell <peter.maydell@linaro.org>,
Alistair Francis <alistair.francis@wdc.com>,
Luc Michel <luc.michel@greensocs.com>,
qemu-devel@nongnu.org
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [Qemu-devel] [RFC PATCH] gdbstub: Avoid NULL dereference in gdb_handle_packet()
Date: Fri, 18 Jan 2019 12:22:13 +0100 [thread overview]
Message-ID: <20190118112213.11173-1-philmd@redhat.com> (raw)
The "Hg" GDB packet is used to select the current thread, and can fail.
GDB doesn't not check for failure and emits further packets that can
access and dereference s->c_cpu or s->g_cpu.
Add a check that returns "E22" (EINVAL) when those pointers are not set.
Peter Maydell reported:
GDB doesn't check the "Hg" packet failures and emit a
"qXfer:features:read" packet which accesses th
Looking at the protocol trace from the gdb end:
(gdb) set debug remote 1
(gdb) target remote :1234
Remote debugging using :1234
Sending packet:
$qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Ack
Packet received: PacketSize=1000;qXfer:features:read+;multiprocess+
Packet qSupported (supported-packets) is supported
Sending packet: $vMustReplyEmpty#3a...Ack
Packet received:
Sending packet: $Hgp0.0#ad...Ack
Packet received: E22
Sending packet: $qXfer:features:read:target.xml:0,ffb#79...Ack
[here is where QEMU crashes]
What seems to happen is that GDB's attempt to set the
current thread with the "Hg" command fails because
gdb_get_cpu() fails, and so we return an E22 error status.
GDB (incorrectly) ignores this and issues a general command
anyway, and then QEMU crashes because we don't handle s->g_cpu
being NULL in this command's handling code.
Fixes: c145eeae1cc
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
RFC because these are many if..break but I can't think of a cleaner way
today.
The protocol isn't specific about the error, can it be "E03" for ESRCH
(No such process)?
---
gdbstub.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/gdbstub.c b/gdbstub.c
index bfc7afb509..480005b094 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1306,6 +1306,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
put_packet(s, "OK");
break;
case '?':
+ if (!s->c_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
/* TODO: Make this return the correct value for user-mode. */
snprintf(buf, sizeof(buf), "T%02xthread:%s;", GDB_SIGNAL_TRAP,
gdb_fmt_thread_id(s, s->c_cpu, thread_id, sizeof(thread_id)));
@@ -1394,6 +1398,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
/* Detach packet */
pid = 1;
+ if (!s->c_cpu || !s->g_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
if (s->multiprocess) {
unsigned long lpid;
if (*p != ';') {
@@ -1429,6 +1437,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
put_packet(s, "OK");
break;
case 's':
+ if (!s->s_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
if (*p != '\0') {
addr = strtoull(p, (char **)&p, 16);
gdb_set_cpu_pc(s, addr);
@@ -1441,6 +1453,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
target_ulong ret;
target_ulong err;
+ if (!s->s_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
ret = strtoull(p, (char **)&p, 16);
if (*p == ',') {
p++;
@@ -1463,6 +1479,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
}
break;
case 'g':
+ if (!s->g_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
cpu_synchronize_state(s->g_cpu);
len = 0;
for (addr = 0; addr < s->g_cpu->gdb_num_g_regs; addr++) {
@@ -1473,6 +1493,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
put_packet(s, buf);
break;
case 'G':
+ if (!s->g_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
cpu_synchronize_state(s->g_cpu);
registers = mem_buf;
len = strlen(p) / 2;
@@ -1485,6 +1509,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
put_packet(s, "OK");
break;
case 'm':
+ if (!s->g_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
addr = strtoull(p, (char **)&p, 16);
if (*p == ',')
p++;
@@ -1504,6 +1532,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
}
break;
case 'M':
+ if (!s->g_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
addr = strtoull(p, (char **)&p, 16);
if (*p == ',')
p++;
@@ -1642,6 +1674,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
put_packet(s, "OK");
break;
} else if (strcmp(p,"C") == 0) {
+ if (!s->g_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
/*
* "Current thread" remains vague in the spec, so always return
* the first thread of the current process (gdb returns the
@@ -1745,6 +1781,10 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf)
const char *xml;
target_ulong total_len;
+ if (!s->g_cpu) {
+ put_packet(s, "E22");
+ break;
+ }
process = gdb_get_cpu_process(s, s->g_cpu);
cc = CPU_GET_CLASS(s->g_cpu);
if (cc->gdb_core_xml_file == NULL) {
--
2.17.2
next reply other threads:[~2019-01-18 11:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 11:22 Philippe Mathieu-Daudé [this message]
2019-01-19 14:50 ` [Qemu-devel] [RFC PATCH] gdbstub: Avoid NULL dereference in gdb_handle_packet() Luc Michel
2019-02-02 18:26 ` no-reply
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=20190118112213.11173-1-philmd@redhat.com \
--to=philmd@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=edgar.iglesias@xilinx.com \
--cc=luc.michel@greensocs.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 NNTP newsgroup(s).