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 1rAZmF-007EdB-1M for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Dec 2023 18:04:11 +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 1rAZmD-0055hD-FG for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Dec 2023 18:04:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rAZmD-0055h4-4p for pgsql-hackers@lists.postgresql.org; Tue, 05 Dec 2023 18:04:09 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rAZmA-00AG4T-EE for pgsql-hackers@postgresql.org; Tue, 05 Dec 2023 18:04:08 +0000 Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-7b357e43cc2so167935639f.1 for ; Tue, 05 Dec 2023 10:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701799444; x=1702404244; darn=postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bCpA3uoZCgQ4jhjYqboAuCGoBo+BEM9cXkH9cNyTcJc=; b=MWfsv/Nnzg+nI75UDgknBbI3TjfCjph58dVZUnKc8/XtLL3FIrI43nuQFaSXF1eSpi lwimnKW4U3buIF6T4rBLdDZWHv0/FQN635u7bmtUXfJeQ/0GLOovH226j+JMCtjGdy/F WuHJcE772dxHrBfgLaHrdLywcZpfGFyF22tLEvDmGg3jcnlMo9PQi4OQFN+FIvMiexlv iI+Zn75LiIZ1V+UNJmfbnjHJre0j8mL5aiePt+gpNdlz6kz7wgE+2NDr7vQbXa63AxgH bvEXE2luhFEBro3eluNyy/yTdDpy+N9UPQe7kivVw/TvyfSgaDo2G3KJtKJOiGHcFCQc v1XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701799444; x=1702404244; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bCpA3uoZCgQ4jhjYqboAuCGoBo+BEM9cXkH9cNyTcJc=; b=u9rD1BFeVZXdaUGpZS9DRog8ySOCfMciyAqIubjQTrvT8XkZ+nT7krTy3sMdWWf0KL znqtQZ5QYU/LAlMjvhW0IVBz0kkxRkc0ZkC0kljbYhQAdmvYTQ9ahviDg4vslvz8Ozwz /ShLMH3aDmgH3tSQC+1sNJigMW0SIaSBy4MA4MFqsAoXQE405ki6BDWDP+lD4V8VR4I/ uyNqgwy5quaKkFNLQlZLOIqKwXMihx/yoUOxWlwMI86YhXlEPQgzSaIdefxrKygdBQEA 88CShxDsjAe80uiu/7OT4awgRRK+grS38ylNt5GRZYmh99ACboc3F5d42Qj/b514609A 9rSw== X-Gm-Message-State: AOJu0YxWfVMuP1kYktudg27RuOffu9lXB7sb9+/9mlVXSYuFsVWO4fP5 dsbp5RhQgk1/dVO1ytF8ehc8Kvker+I= X-Google-Smtp-Source: AGHT+IEQEtcNd+Umb9sXfZFyMonkoYqlibiYWpYwN0w6q3VJNSOgqh7ccvV3Wi60EtdW2jMMbUYUnA== X-Received: by 2002:a05:6602:3794:b0:7b3:9687:ecfc with SMTP id be20-20020a056602379400b007b39687ecfcmr5304349iob.18.1701799444460; Tue, 05 Dec 2023 10:04:04 -0800 (PST) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id c5-20020a02a605000000b0043a180a7a94sm3246993jam.121.2023.12.05.10.04.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 10:04:03 -0800 (PST) Date: Tue, 5 Dec 2023 12:04:02 -0600 From: Nathan Bossart To: Thomas Munro Cc: pgsql-hackers Subject: Re: UBSan pointer overflow in xlogreader.c Message-ID: <20231205180402.GB2757816@nathanxps13> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Dec 06, 2023 at 12:03:53AM +1300, Thomas Munro wrote: > xlogreader.c has a pointer overflow bug, as revealed by the > combination of -fsanitize=undefined -m32, the new 039_end_of_wal.pl > test and Robert's incremental backup patch[1]. The bad code tests > whether an object could fit using something like base + size <= end, > which can be converted to something like size <= end - base to avoid > the overflow. See experimental fix patch, attached. The patch LGTM. I wonder if it might be worth creating some special pointer arithmetic routines (perhaps using the stuff in common/int.h) to help prevent this sort of thing in the future. But that'd require you to realize that your code is at risk of overflow, at which point it's probably just as easy to restructure the logic like you've done here. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com