From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=hNjWgeoBaL/djd3JsNae+o1iUFcqtOQYB1H4m/z8Vww=; b=MwMc/kYSH6z7AsUtElsE13dPT+g8tZKci1RJINzzBsrpQt87onzuSbHvBVMxiSWO3Y MlybNL24VpT6gUQP86fLafBCiDHiPBbyf7r4cO/yWnLiS/cookN4faFIWxWDdMFSQ5Be XhhNnkcIPttb+ETTeWfdtU6eRFVtqslbx8064Kll1yz58TIayOsvINSZbTwISPXjROOo +0ASceBojgb8lu7PvLSfbtePWu5dRQ0D554+dN2ylzOMTMldpAJQfGN8/mDuZWXcrT8K LMeJoPcWIsH/mmtuTEghFBeVoG8Nt66Adbl1QpZBiWiHgSSAylHhAYjxvD2R8TuNAqOY F7dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=hNjWgeoBaL/djd3JsNae+o1iUFcqtOQYB1H4m/z8Vww=; b=hIo5Hm9CZkiymesPkezzjQBlXitLQvgsOyqe9uTGGpJiQXwbRTnRKNqsPIsNtVXEVK 0sLMT7blJorPaFR/Az0+3ier73yxSsYQUMSvbnrip099ata5INiVL++FdeQeDnnB4uNL mQqHL/CFT7FIo6LJcfB1I6BWCChwgqh/0KPGCdIw6y7J7VdAF0sUmq0m0ZLqTl6lVhhI dIpWdFfPiYa2OyguQhfIPkjEAvpsZCP3Ih50MiuC/qpk2IWmJk6maBx9LTpEv5CXxL8C LZh6kA2bfupSDL4jxoLhTg45r1RL1XFx0veYjsf6sDRos5BRPGqRG8Zdv5CTfxBA0o+I 7BKQ== X-Gm-Message-State: AOAM532ZthaacjqeYqoHdxAM1thYTu+X9wFWbpI4Ff8gNclhu3lTA++P yBpoB+16YLXxkcPnqSj6q2EqEkiZYhY= X-Google-Smtp-Source: ABdhPJyn/H7U9vh7OtpCEcGEIP36exyVQZl13GrkmERQChZSnJGnOvLsqJ0H66kVX7UfEuL2ZZQEAw== X-Received: by 2002:ac2:4d12:: with SMTP id r18mr3086890lfi.354.1604411223062; Tue, 03 Nov 2020 05:47:03 -0800 (PST) Sender: "Ivan A. Melnikov" Date: Tue, 3 Nov 2020 17:47:00 +0400 From: "Ivan A. Melnikov" To: ALT Linux Team development discussions Message-ID: <20201103134700.viigwhhxgqbswdki@titan.localdomain> References: <20201030213543.9C351844021E@gitery.altlinux.org> <20201102221840.GA24969@altlinux.org> <20201103121105.GA1841@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201103121105.GA1841@altlinux.org> Cc: Alexey Appolonov Subject: Re: [devel] [SCM] packages/bash3: heads/p9 X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 13:47:05 -0000 Archived-At: List-Archive: List-Post: On Tue, Nov 03, 2020 at 03:11:05PM +0300, Dmitry V. Levin wrote: > On Tue, Nov 03, 2020 at 04:32:08AM +0300, Alexey Appolonov wrote: > > 03.11.2020 01:18, Dmitry V. Levin пишет: > > > On Fri, Oct 30, 2020 at 09:35:43PM +0000, Alexey Appolonov wrote: > > >> Update of /people/alexey/packages/bash3.git > > > [...] > > >> commit 0db3057724a11b6e9f3bdca6a831370443aaa06e > > >> Author: Alexey Appolonov > > >> Date: Tue Oct 27 14:36:56 2020 +0300 > > >> > > >> Preventing a segmentation fault in '_evalfile' func of 'evalfile.c' > > >> > > >> Index 'result' can be -1; The index is checked from the top also > > >> (just in case). > > > Prevent a potential segmentation fault ... > > > > > >> commit 6c6399d5a7cb51ae53c196f0bfdfd92e43711544 > > >> Author: Alexey Appolonov > > >> Date: Tue Oct 27 13:53:08 2020 +0300 > > >> > > >> Preventing a segmentation fault in 'make_redirection' func of 'make_cmd.c' > > >> > > >> Index 'wlen' is -1 if a length of 'w->word' C-string is 0. > > > Likewise. > > > > > > [...] > > >> diff --git a/bash/builtins/evalfile.c b/bash/builtins/evalfile.c > > >> index d05bc7b..9eec1a5 100644 > > >> --- a/bash/builtins/evalfile.c > > >> +++ b/bash/builtins/evalfile.c > > >> @@ -149,7 +149,8 @@ file_error_and_exit: > > >> > > >> string = (char *)xmalloc (1 + file_size); > > >> result = read (fd, string, file_size); > > >> - string[result] = '\0'; > > >> + if (result >= 0 && result <= file_size) > > >> + string[result] = '\0'; > > >> > > >> return_val = errno; > > >> close (fd); > > > Adding a check for result <= file_size? Really? Do you suppose that > > > read (fd, string, file_size) is ever capable of returning a value > > > greater than file_size? > > > > I just think that the comfort of having such checks outweighs > > the negligible computational costs that they bring. > > If read(2) could write more bytes than requested, then the buffer > would be overwritten before the check you're suggesting to add. [...] IMO the interesting part here is not in read syscall semantics, but in the types involved. As far as I understand, result is int here, and read returs ssize_t. If sizeof(ssize_t) > sizeof(int) (e.g. on x86_64), given large enough input file and enough memory, read can read more than 2^31 bytes and overflow result variable; this may lead to such result value that (result <= file_size) will evaluate to false (file_size is size_t, so result will be promoted to usigned long before comparison). It seems to me that this is possible only when result is negative, so the first check (result >= 0) makes the second one unnecessary, but I would not dare to call this obvious. -- wbr, iv m.