From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14319 invoked by alias); 11 Dec 2013 00:25:07 -0000 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 Received: (qmail 14306 invoked by uid 89); 11 Dec 2013 00:25:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f73.google.com Received: from Unknown (HELO mail-qa0-f73.google.com) (209.85.216.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 11 Dec 2013 00:25:06 +0000 Received: by mail-qa0-f73.google.com with SMTP id o15so17890qap.2 for ; Tue, 10 Dec 2013 16:24:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=JWCgWZ4lPyr6IKBNdCUAaqy3TZ3Yfpnaep40kPhgJhI=; b=YSw0IOlqzw09J5vSp30Ef2LrQnyShYiFFq0vi2UQf6O7ZWxE6yheF7oLs2a/AuHfzE glvL9z9JRhNPzGFPIhJKrxIHqNYOCaZ2N4xEn+zeU953M4iGHap0YB3m6Y7FjNbFvI6f ArkV7M7GdDi/DktQre+nqNLoihJ5GAGcouAuVP3iGFMIvyUuvm/EPkzzeWr2l6uy1lE4 lzL+rx0zZFeJ6rUmAxlawCkaZl9KF+LpiD8gf4itbiutmWUn1e1HHBbv8kuFIHUfwATT UY4fcyu+0uwe/lda0F6NLxK4Hu8AGb47HBiFuKUejZTPrKHsAnsv+apI3rgO5FyKbKXU U7Bg== X-Gm-Message-State: ALoCoQmFI/HZvslWsZBWu+l7hyFDbmUUOiTRTXcUszCuqchPUU6tjcpcgrbO7YqP80vPUIrTYuN4SBgLfQZDE5g0iDDuWSUtULLdXiStJU7LSP+t7TSuU73W2xfa20npHuPmuKaPf4A3/ytNJZeNxek5GCp1FT9QIvvkuukHZD95McLn/E+WIf8lu9EKKsDTbky180AM27Zv8rBKn7e5RgjmVQR6pgZhog== X-Received: by 10.224.122.210 with SMTP id m18mr8716056qar.2.1386721497691; Tue, 10 Dec 2013 16:24:57 -0800 (PST) Received: from corp2gmr1-2.hot.corp.google.com (corp2gmr1-2.hot.corp.google.com [172.24.189.93]) by gmr-mx.google.com with ESMTPS id c8si1458734yhk.7.2013.12.10.16.24.57 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Dec 2013 16:24:57 -0800 (PST) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-2.hot.corp.google.com (Postfix) with ESMTP id D1ACC5A41C6; Tue, 10 Dec 2013 16:24:56 -0800 (PST) From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21159.45272.300672.237174@ruffy.mtv.corp.google.com> Date: Wed, 11 Dec 2013 00:25:00 -0000 To: Pedro Alves Cc: gdb-patches , Joel Brobecker , Sterling Augustine Subject: Re: [PATCH] PR 16286: Reading python value as string beyond declared size In-Reply-To: <529F1654.8000704@redhat.com> References: <529E3F10.6030607@redhat.com> <529F1654.8000704@redhat.com> X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00398.txt.bz2 Pedro Alves writes: > On 12/03/2013 11:01 PM, Doug Evans wrote: > > On Tue, Dec 3, 2013 at 12:29 PM, Pedro Alves wrote: > >> On 12/02/2013 11:14 PM, Doug Evans wrote: > >>> + if (*length > 0) > >>> + fetchlimit = UINT_MAX; > >> > >> Shouldn't this be: > >> > >> if (*length > 0) > >> fetchlimit = *length; > >> > >> ? That is, if the caller specified a limit, why do we do over it? > > > > read_string will take min (len, fetchlimit), and I saw no value in > > passing fetchlimit = *length. > > Ah, I see now. Thanks. Thanks. Committed. > >> BTW, it looks like the not_lval/lval_internalvar path can > >> blindly read beyond the value's contents buffer, if *length > >> is bigger than the value's contents buffer size: > > It didn't look right to me either, but I was leaving digging deeper > > for another pass. > > OK. TBC, I wasn't requesting that'd be fixed in this patch, only > for confirmation that I wasn't missing something. I filed https://sourceware.org/bugzilla/show_bug.cgi?id=16313