From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id o9rAFFoQRWoPJSEAWB0awg (envelope-from ) for ; Wed, 01 Jul 2026 09:04:26 -0400 Received: by simark.ca (Postfix, from userid 112) id 3AD261E024; Wed, 01 Jul 2026 09:04:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 60AD61E024 for ; Wed, 01 Jul 2026 09:04:25 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 829A34BA23FF for ; Wed, 1 Jul 2026 13:04:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 829A34BA23FF Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by sourceware.org (Postfix) with ESMTPS id E461C4BA2E31 for ; Wed, 1 Jul 2026 13:04:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E461C4BA2E31 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E461C4BA2E31 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.52 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782911041; cv=none; b=O+clhy8Yoz2TsoxrSHDkw2pI+MD3mjvnMHzNxAwNu5uDY05OAl64UHIIjHqmcvg+dCVBIuooSyXOYQbd/Smgu4VZFKRmXpXgkBcjnvfqiCjw+w/1FTf/wHsxwF4ssm6mAjzVauYxdr4bBwZev3ErlH6dMTRWacgKzW8wOSpKF3Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782911041; c=relaxed/simple; bh=pwhqh1D4oJBEei78sJ59VlJgJCuO/twVsGsDL9q+enM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=Zv0TDQfpP7WY8nUuF3UPNcuirnW8cRugfPPJnQ2zIlwq/HjNJX72DBD5OH7GGd6/2wrK7JdpDQQ4Dx+yHhUceiBLDYE012SYZQvBf3S4epsTDKNFPJG/SfXxx3GTkJrHAZ16cl+2p0lMPQsLGohe5XWMNX209BRpPwGarNI0lms= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E461C4BA2E31 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49241dbf9c1so5122295e9.2 for ; Wed, 01 Jul 2026 06:04:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782911040; x=1783515840; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=woNlPQ+7tM7DO5qZ6zCUYzEW8gwNHuCWsLYeeqLUTyc=; b=NX6i+s6HYkiLSz7T2GyRNiOlhIZfrf57l5miTupLQ2ojFysy3e/HjdYQn+tjx/3QLJ nvXSIYkTPt/i9ZpVAyo0JlnpV6fZloUutMMaUNrqkKORZMJVnD8J0+MceRVr88PuEZKm QYk29qvpUAWJjKavjYnNosE/qe1EO1/G4Jdy8ICaGab3n+G51CLGyQIF9t+zd/AkGR+m 3z77QNiUjNEAYh/E4VgYnlt6SoSLOxHHeAYuYzox6dPoRXab03xLJCDWIvhqTDwYXMDi OupC5NkTkMe4ICiYz1E1rR/zW7wtD9r6lSORAvABbYAa/XIGEoTxBdgY8Vhzkw/WgFkf wpNg== X-Forwarded-Encrypted: i=1; AFNElJ/RtRvwf2EIz9PxjIA0Stcf2EDtdT+wLT6wdqFZxPIFrzjwi0tQH2NNT9GeeGkwKLmAGbppSwHSmKXkog==@sourceware.org X-Gm-Message-State: AOJu0YwHICjJMSyMvCxiBWfTUl6hn5YlNGq6v8l36gHe/Cc8iNMTN2MU fRme1wYKmelCyZ5Zh/Vvcbrs1AiIyGtTRhTQWSVfs16O4EgD+PqQqFPH X-Gm-Gg: AfdE7ckLYbeNICpa0aJXMTL9faMmK4ttqWFoyrBtWY4Y4bdMYjAXogzqNjbkqc7+2My lPI4ShplC2PGvVIFRDm+PxTcl9rLgDIHUS3tu2qquEMzDAo0DqZMu4575RWjT3yWwow8Yqpmmd4 mP8Xp7ppqJzvaJWEYXwRIY1LI3qh3efU0hem0oQMZDvnrQbrcyVBe1BiIC+6vmirCt0t7AqmIuG Godk290DTzI06Jilzjc2zOiUWKAyPHdBKTZ3CXT30N9Q5dwslVTwbxP5MvtqXdAGiOUU5+dEXrr gYc7NFddsh7qvO331BOt5svcewRbXIIkzgcOg7RkisKfThd19F9vupCmTNZgIDf5EhCpXmBbCgR RXvolwUYSB2GgX9TRvrnxW8MTzRQc6QLjINNGhnUvgSDux9tXGSoRKWqq3/1S0C7pIeVZ61iojp hpj3k3isOjwDtc0BVvxGfORp3UNP9BXBoTGg9UIZcwnDj5r+ZevuSbDBY= X-Received: by 2002:a05:600c:2e43:b0:493:c14a:a1ca with SMTP id 5b1f17b1804b1-493c3cd4aeemr5568565e9.3.1782911039553; Wed, 01 Jul 2026 06:03:59 -0700 (PDT) Received: from ?IPV6:2001:8a0:fac2:7700:414d:ba43:4748:aa0f? ([2001:8a0:fac2:7700:414d:ba43:4748:aa0f]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47563d195b3sm17554210f8f.8.2026.07.01.06.03.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2026 06:03:58 -0700 (PDT) Message-ID: <519bd2f3-243e-42c3-a122-4edbb757878b@palves.net> Date: Wed, 1 Jul 2026 14:03:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: replace alloca with gdb::char_vector in remote-fileio.c To: Luis Machado , gdb-patches@sourceware.org References: <20260630095238.1700797-1-luis.machado@amd.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <20260630095238.1700797-1-luis.machado@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-06-30 10:52, Luis Machado wrote: > static int > -remote_fileio_extract_ptr_w_len (char **buf, CORE_ADDR *ptrval, int *length) > +remote_fileio_extract_ptr_w_len (char **buf, CORE_ADDR *ptrval, int *length, > + bool allow_zero_length = false) > { > char *c; > LONGEST retlong; > @@ -211,6 +215,11 @@ remote_fileio_extract_ptr_w_len (char **buf, CORE_ADDR *ptrval, int *length) > *buf = c; > if (remote_fileio_extract_long (buf, &retlong)) > return -1; > + /* Reject negative lengths, zero (unless the caller permits it for the > + Fsystem NULL-cmdline sentinel), and lengths above PATH_MAX to prevent > + out-of-bounds memory reads or oversized heap allocations. */ > + if (retlong < 0 || (!allow_zero_length && retlong == 0) || retlong > PATH_MAX) > + return -1; PATH_MAX is NOT guaranteed to exist. It's a portability hazard. Note how the only place in common code that uses it, in inf-child.c, has "#if defined (PATH_MAX)" guarding it. The uses in remote-fileio.c itself are guarded by __CYGWIN__. POSIX allows PATH_MAX to be undefined when the limit is indeterminate. GNU/Hurd is the canonical case, it has no PATH_MAX at all. On Windows, there's MAX_PATH (not a typo, it's really the reserve word order of PATH_MAX), defined as 260, though syscalls allow more than that. gnulib's import/pathmax.h does give us PATH_MAX on Windows (but not on Hurd, see comments there), but also defined as 260. On macOS PATH_MAX is 1024, but some syscalls accept longer. Etc. The GNU conventions is just to not code a limit, and use dynamic allocation. The patch already switches from alloca to the heap, so we can just drop the PATH_MAX cap. The buffers are transient and passed to open, stat etc. syscalls immediately, and release immediately. The syscalls fail with ENAMETOOLONG if truly passed a too-long name, so the cap adds zero safety. > *length = (int) retlong; > return 0; > } > @@ -305,7 +314,6 @@ remote_fileio_func_open (remote_target *remote, char *buf) > long num; > int flags, fd; > mode_t mode; > - char *pathname; > struct stat st; > > /* 1. Parameter: Ptr to pathname / length incl. trailing zero. */ > @@ -339,8 +347,8 @@ remote_fileio_func_open (remote_target *remote, char *buf) > } > > /* Request pathname. */ > - pathname = (char *) alloca (length); > - if (target_read_memory (ptrval, (gdb_byte *) pathname, length) != 0) > + gdb::char_vector pathname (length); "pathname" never needs to be resized, so std::vector adds a bit of useless weight (it needs to track storage vs size separately, etc.). Make it a gdb::unique_xmalloc_ptr instead. That's the only change needed, all the rest of the code will work the same. (Ditto for all the other instances. You do have one resize call further below, but that's not a real resize, it's still just initialization.)