From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22953 invoked by alias); 2 Mar 2011 16:51:58 -0000 Received: (qmail 22944 invoked by uid 22791); 2 Mar 2011 16:51:57 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Mar 2011 16:51:46 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p22Gpc5P032172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Mar 2011 11:51:38 -0500 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p22Gpagx005326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 11:51:38 -0500 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p22GpaAN003422; Wed, 2 Mar 2011 17:51:36 +0100 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id p22GpZN0003420; Wed, 2 Mar 2011 17:51:35 +0100 Date: Wed, 02 Mar 2011 16:51:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [patch] [gdbserver] Fix memory corruption Message-ID: <20110302165135.GA29531@host1.dyn.jankratochvil.net> References: <20110301213428.GA15991@host1.dyn.jankratochvil.net> <201103021535.16716.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103021535.16716.pedro@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00108.txt.bz2 On Wed, 02 Mar 2011 16:35:16 +0100, Pedro Alves wrote: > On Tuesday 01 March 2011 21:34:28, Jan Kratochvil wrote: > > To make it easily reproducible one can disable try_rle() by patching it: > > +return 1; > > /* Don't go past '~'. */ > > I can't reproduce it. You may need also -lmcheck for gdbserver. > > 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. remote_escape_output is called with OUT_MAXLEN == PBUFSIZ - 2 == 16382 and returns it +1, therefore 16383. #8 0x0000000000404ca3 in putpkt_binary_1 (buf=0x258f2c0 "mmn"..., cnt=16381, is_notif=0) at remote-utils.c:801 801 free (buf2); Maybe your system does not have # cat /proc/*/cmdline|tr -cd '$#}*'|wc -c 84 > 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. Yes, the request is just for 16378 but gdbserver returns more. > 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. Before starting to chase off-by-one here and off-by-one there what is the practical purpose of such strict packet limits? When TCP is in use shouldn't the code all around just support arbitrary packet sizes? To get rid any constant buffer sizes etc. Then there still can remain some vague fragmentation on the GDB client side but both sides should be able to accept arbitrary packet sizes, shouldn't they? Thanks, Jan