Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rutx6-008OC1-GF for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Apr 2024 12:54:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rutx5-00HZlH-AB for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Apr 2024 12:54:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rutx4-00HZl9-P3 for pgsql-hackers@lists.postgresql.org; Thu, 11 Apr 2024 12:54:50 +0000 Received: from meesny.iki.fi ([2001:67c:2b0:1c1::201]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rutwx-002LYx-1V for pgsql-hackers@postgresql.org; Thu, 11 Apr 2024 12:54:49 +0000 Received: from [172.19.157.206] (unknown [212.174.35.38]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by meesny.iki.fi (Postfix) with ESMTPSA id 4VFfmF1GWwzyT2; Thu, 11 Apr 2024 15:54:37 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1712840078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=arC45dkLvTNUbfaUuznMeQ3sz3zjVLehPmSaRxngX/0=; b=pxi8j/BFJWrYfoucUeXuIyV9xHNo+AOvNl3MyGaIgTLqEA1Py5cw4gn/L+3+T5b2vWbf1k TWOSmx5OwKXMaSAlN8dRNnxCTmqclNMUYiHA05pwBsSxXu66y53X/6EevmiE+njuoy8phA qqSe6XA2NMNXb8wKAIHNAByHzi0eFp4= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1712840078; a=rsa-sha256; cv=none; b=C91Xjs3TKhyNrxGp+tHTl7ZgH20kdgVR6TQZGwrZ+SnjtlLW5u1i0u9fiVmFwZ4CUb8s4G YLGOE9lvdPAsW+YJk6A9UFJyvLtExAxQ5VbfrTg0+NuW3OBjWKWvc/PQhzdikGzvupYdAV AFioArRtsg9dqE6pfl2az2oYkKSgu0U= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1712840078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=arC45dkLvTNUbfaUuznMeQ3sz3zjVLehPmSaRxngX/0=; b=R4n2yzCYK+lzOUEuAFXeryX7h5isvXjM4lBhNIAWgrrTW61uQdmSOOHpon7zMhtCDTfs9D g2oli8zKSEHqEqNbFexKTp/wPUsLtfbzbXG47mjGG/bcXQFwqshPohSi8LuDct5gqll8Up mGqCQZpKkpAG8tHhlTgEluRIcUUjIF8= Message-ID: <5967fcdc-0211-4549-8ade-03d21ccf7566@iki.fi> Date: Thu, 11 Apr 2024 15:54:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c) To: Ranier Vilela Cc: Pg Hackers References: <02c62e7e-df6b-4b50-8b9e-cdcb3b45c74e@iki.fi> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/04/2024 15:03, Ranier Vilela wrote: > Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas > > escreveu: > > On 10/04/2024 21:07, Ranier Vilela wrote: > > Hi, > > > > Per Coverity. > > > > The function ReorderBufferTXNByXid, > > can return NULL when the parameter *create* is false. > > > > In the functions ReorderBufferSetBaseSnapshot > > and ReorderBufferXidHasBaseSnapshot, > > the second call to ReorderBufferTXNByXid, > > pass false to *create* argument. > > > > In the function ReorderBufferSetBaseSnapshot, > > fixed passing true as argument to always return > > a valid ReorderBufferTXN pointer. > > > > In the function ReorderBufferXidHasBaseSnapshot, > > fixed by checking if the pointer is NULL. > > If it's a "known subxid", the top-level XID should already have its > ReorderBufferTXN entry, so ReorderBufferTXN() should never return NULL. > > There are several conditions to not return NULL, > I think trusting never is insecure. Well, you could make it an elog(ERROR, ..) instead. But the point is that it should not happen, and if it does for some reason, that's very suprpising and there is a bug somewhere. In that case, we should *not* just blindly create it and proceed as if everything was OK. -- Heikki Linnakangas Neon (https://neon.tech)