From patchwork Thu Apr 2 07:09:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Steinhardt X-Patchwork-Id: 11470181 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9712515AB for ; Thu, 2 Apr 2020 07:09:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 75B1520784 for ; Thu, 2 Apr 2020 07:09:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=pks.im header.i=@pks.im header.b="L3ujEh93"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="S4yo+W7Y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733114AbgDBHJS (ORCPT ); Thu, 2 Apr 2020 03:09:18 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:60571 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728612AbgDBHJR (ORCPT ); Thu, 2 Apr 2020 03:09:17 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 08E8C5C028F; Thu, 2 Apr 2020 03:09:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 02 Apr 2020 03:09:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=kXhCDV4jmHqEtHWXlMbTY/O6mzR l0JCm4WOa10GSc9M=; b=L3ujEh93gUWbzdOK/V7eOOYaCe3+wffIj/hcWecsVw2 lSZ9n8xs2RiMXVXB9wi8WYwYU+SUSRsO+hQgMyl8cuou8wihYBXlkD7YDUVpOvWk WboVX1rfEKkm6FwBHvMDTTdg6TZ+5JFYhMBcl/bkPGtsNWsW75gGN850hp6xYR2f t8yKKLBL9fg3eCHY84dr9DMdJ5XOEs2IFzd9DIzi3lpx94fvoztOBkCi9EI3FFli 5HApLccnslJ/2OK2e9r9a1AhG4RYikXf3qFSRNjAVyno8KZ8zwIdj2/2NdfzV33c jmjIL4Ty86LaVn3I56V09qc+Ivd+nkzAK1weRTGen2w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=kXhCDV 4jmHqEtHWXlMbTY/O6mzRl0JCm4WOa10GSc9M=; b=S4yo+W7YNAwxuRKCoCbCeo 2j2xHASPjm/gBdFBQ3jGjg7go7Zh6vjzBC2kw/FOgCi0efMklN7sRRLteDQH/a8X 657Rp16PIgMiuoNJcqCHDSbkB0f+J6QmFHRTPu1g/Updfs9F6q5N24kk/3BRlZgW +oPe7dXRpmn0QuZeb0168w0PlQfanH3o+/M245f8yqxljYlbimjyG5kyi9G1jPBr NClW3Bafx8uXprH+Yn3uoI6jErkTkji15Y0sfllMd+EE7aRKGTaVm0o32ID5asUf D6UJ9GaRW1e6ExSyy4CkHFfAaUVVWicJLNOZzL8qKZskPKfxZFgS1h+ibqbvvpRw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdefgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrrghtrhhi tghkucfuthgvihhnhhgrrhguthcuoehpshesphhkshdrihhmqeenucfkphepkeelrdduvd drleegrddvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehpshesphhkshdrihhm X-ME-Proxy: Received: from vm-mail.pks.im (x590c5e1c.dyn.telefonica.de [89.12.94.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 68B8E306CD75; Thu, 2 Apr 2020 03:09:16 -0400 (EDT) Received: from localhost (ncase [10.192.0.11]) by vm-mail.pks.im (OpenSMTPD) with ESMTPSA id 4dcf2220 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 2 Apr 2020 07:09:15 +0000 (UTC) Date: Thu, 2 Apr 2020 09:09:22 +0200 From: Patrick Steinhardt To: git Cc: Christian Couder , Junio C Hamano Subject: [PATCH v3 1/9] refs: fix segfault when aborting empty transaction Message-ID: <7a297db4daaee84dc90ddeaa8f77b68a39231ef1.1585811013.git.ps@pks.im> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org When cleaning up a transaction that has no updates queued, then the transaction's backend data will not have been allocated. We correctly handle this for the packed backend, where the cleanup function checks whether the backend data has been allocated at all -- if not, then there is nothing to clean up. For the files backend we do not check this and as a result will hit a segfault due to dereferencing a `NULL` pointer when cleaning up such a transaction. Fix the issue by checking whether `backend_data` is set in the files backend, too. Signed-off-by: Patrick Steinhardt --- refs/files-backend.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index 561c33ac8a..6516c7bc8c 100644 --- a/refs/files-backend.c +++ b/refs/files-backend.c @@ -2565,17 +2565,19 @@ static void files_transaction_cleanup(struct files_ref_store *refs, } } - if (backend_data->packed_transaction && - ref_transaction_abort(backend_data->packed_transaction, &err)) { - error("error aborting transaction: %s", err.buf); - strbuf_release(&err); + if (backend_data) { + if (backend_data->packed_transaction && + ref_transaction_abort(backend_data->packed_transaction, &err)) { + error("error aborting transaction: %s", err.buf); + strbuf_release(&err); + } + + if (backend_data->packed_refs_locked) + packed_refs_unlock(refs->packed_ref_store); + + free(backend_data); } - if (backend_data->packed_refs_locked) - packed_refs_unlock(refs->packed_ref_store); - - free(backend_data); - transaction->state = REF_TRANSACTION_CLOSED; }