From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4524 invoked by alias); 2 Mar 2011 15:35:25 -0000 Received: (qmail 4335 invoked by uid 22791); 2 Mar 2011 15:35:24 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Mar 2011 15:35:20 +0000 Received: (qmail 25995 invoked from network); 2 Mar 2011 15:35:18 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Mar 2011 15:35:18 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] [gdbserver] Fix memory corruption Date: Wed, 02 Mar 2011 15:35:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.0; x86_64; ; ) Cc: Jan Kratochvil References: <20110301213428.GA15991@host1.dyn.jankratochvil.net> In-Reply-To: <20110301213428.GA15991@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103021535.16716.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00106.txt.bz2 On Tuesday 01 March 2011 21:34:28, Jan Kratochvil wrote: > Hi, > > gdb.server/ext-run.exp always crashes during the nightly regression tests: > info os processes > memory clobbered past end of allocated block > Remote communication error. Target disconnected.: Connection reset by peer. > (gdb) FAIL: gdb.server/ext-run.exp: get process list (pattern 1) > > Probably OK to check in but I rather ask. > > To make it easily reproducible one can disable try_rle() by patching it: > +return 1; > /* Don't go past '~'. */ I can't reproduce it. > > So that putpkt_binary_1's cnt == 16383 will overrun PBUFSIZ 16384 by 4 bytes. How did you get that large of a `cnt' in the first place? The largest I get is 16379. gdb does: /* Request only enough to fit in a single packet. The actual data may not, since we don't know how much of it will need to be escaped; the target is free to respond with slightly less data. We subtract five to account for the response type and the protocol frame. */ n = min (get_remote_packet_size () - 5, len); snprintf (rs->buf, get_remote_packet_size () - 4, "qXfer:%s:read:%s:%s,%s", object_name, annex ? annex : "", phex_nz (offset, sizeof offset), phex_nz (n, sizeof n)); that is, you shouldn't get a read request that big. It looks like server.c:handle_qxfer's len caping is forgetting to account for the $, # and checksum (should be fixed), but I don't think that's the real cause in your example, since it only pushes back to gdb as much data as it requested. gdb's putpkt_binary reads: /* Send a packet to the remote machine, with error checking. The data of the packet is in BUF. The string in BUF can be at most get_remote_packet_size () - 5 to account for the $, # and checksum, and for a possible /0 if we are debugging (remote_debug) and want to print the sent packet as a string. */ gdbserver's version does not have that comment, although it should. Both versions lack an assertion catching the case of trying to send too much for the packet buffer size. > > > Thanks, > Jan > > > gdb/gdbserver/ > 2011-03-01 Jan Kratochvil > > * remote-utils.c (putpkt_binary_1): Calculate BUF2 size dynamically. > > --- a/gdb/gdbserver/remote-utils.c > +++ b/gdb/gdbserver/remote-utils.c > @@ -725,7 +725,7 @@ putpkt_binary_1 (char *buf, int cnt, int is_notif) > char *p; > int cc; > > - buf2 = xmalloc (PBUFSIZ); > + buf2 = xmalloc (1 + cnt + 4); > > /* Copy the packet into buffer BUF2, encapsulating it > and giving it a checksum. */ > -- Pedro Alves