From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 34820385D0D5 for ; Fri, 28 Oct 2022 13:56:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34820385D0D5 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x32a.google.com with SMTP id a13-20020a9d6e8d000000b00668d65fc44fso3003349otr.9 for ; Fri, 28 Oct 2022 06:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xD2dJ99PeGC9l6g8qAkeCpo7jw5bbzkqASbtm59uA+k=; b=Ose9dgSC3WmeFLsVHfdXVytFyfWxYU4hMyG/joMfcBx2A6ag4f+uI+xKOuKG0Ft+rO kCdoqTXbiCgKUVdTC3segSDU6FBr984kcmdDykVlzXGgs4lYIICcNjprVruW9JJcQhPX Qbzj18ipwu+kvSSVHhu60GuP+vamjat0aDgyxR61sFTCOVm2mjK0bS57fOWFp1hY2NdC XPGcXJ1eExSaOjJ3/DPnGKFidzKWmM5Z7n9t95KfXdmfZ+GtuF0Xjrj1d0YmQWBECSjR aMei+Mmh82z2FH3vZL47QuFoCkTNfOF1b3X+TBByVps/mD46jlKsieE4n50Wusnrs1eK UYmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xD2dJ99PeGC9l6g8qAkeCpo7jw5bbzkqASbtm59uA+k=; b=OHvD5ntNti9VyKFb1DmqfOiPcx1rosTsCyleMSxQHoS0Rwe2V3XskzRXMr57K5SWOY 0rQ0c6kIezomg5q2k25/IEawaOCdx8NBjqT2ZuCYKolaCWgk1vcAa5RmPHfEZJfJfuJt qD2RGAkPS266EGTNrhU8dxZBa+tmbkD7RC1RFzByaoa6BqogFV3l3UBT5xRUtEt/4sfw sBEUtIUxACGG8TqjK+pKSk/uj+xqPwMdS5YGIv3lt0hpfU7VY679zBlh8snaoHOPq/6T ZiO5bL4uVnGuGYECJToMMpYIqvk/CPBVl6tDClVcWZ4BXKs1sS248Lotj1/i6ceKiwjI Cl5A== X-Gm-Message-State: ACrzQf2H3Lhz3Eqs+fNMPPv/gLtfHuYOW69bHxvlAeQhkxIPAHwcRK88 WBoD8ZjQ0FWO9Jep1yYtiJ/SRw== X-Google-Smtp-Source: AMsMyM4tMF/eakNlM4JrB3xyU9eJLwBDCr8k6Pac822Zb/lFw++Cl+z+3j14XivMP82aqTdK0QAEhA== X-Received: by 2002:a9d:3642:0:b0:655:f25f:be55 with SMTP id w60-20020a9d3642000000b00655f25fbe55mr7424068otb.13.1666965364271; Fri, 28 Oct 2022 06:56:04 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:17c8:607a:e74b:8f20:5e5b? ([2804:1b3:a7c0:17c8:607a:e74b:8f20:5e5b]) by smtp.gmail.com with ESMTPSA id g10-20020a9d2d8a000000b0066c2d80c753sm1131695otb.22.2022.10.28.06.56.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 06:56:03 -0700 (PDT) Message-ID: <21fd200b-951b-2997-a1ce-60e2258aff9b@linaro.org> Date: Fri, 28 Oct 2022 10:56:01 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH 11/20] elf: Fix alloca size in _dl_debug_vdprintf Content-Language: en-US To: Szabolcs Nagy , libc-alpha@sourceware.org References: <913439ddce2d33024fa0d0da5d9f4c6234a30cde.1666877952.git.szabolcs.nagy@arm.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <913439ddce2d33024fa0d0da5d9f4c6234a30cde.1666877952.git.szabolcs.nagy@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 27/10/22 12:33, Szabolcs Nagy via Libc-alpha wrote: > The alloca size did not consider the optional width parameter for > padding which could cause buffer underflow. The width is currently used > e.g. by _dl_map_object_from_fd which passes 2 * sizeof(void *) which > can be larger than the alloca buffer size on targets where > sizeof(void *) >= 2 * sizeof(unsigned long). > > Even if large width is not used on existing targets it is better to fix > the formatting code to avoid surprises. > --- > elf/dl-printf.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/elf/dl-printf.c b/elf/dl-printf.c > index 429d2e80c2..00c114002c 100644 > --- a/elf/dl-printf.c > +++ b/elf/dl-printf.c > @@ -163,8 +163,11 @@ _dl_debug_vdprintf (int fd, int tag_p, const char *fmt, va_list arg) > /* We use alloca() to allocate the buffer with the most > pessimistic guess for the size. Using alloca() allows > having more than one integer formatting in a call. */ > - char *buf = (char *) alloca (1 + 3 * sizeof (unsigned long int)); > - char *endp = &buf[1 + 3 * sizeof (unsigned long int)]; > + int size = 1 + 3 * sizeof (unsigned long int); > + if (width + 1 > size) > + size = width + 1; > + char *buf = (char *) alloca (size); > + char *endp = &buf[size]; > char *cp = _itoa (num, endp, *fmt == 'x' ? 16 : 10, 0); > > /* Pad to the width the user specified. */ Would be better to just limit a maximum width and use a fixed-size buffer instead (and assert if size is larger)?