From nobody Sun May 5 00:14:53 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1566566698; cv=none; d=zoho.com; s=zohoarc; b=Ac9bm7WaMALFp6ZC4j5uarfyyVYXZelOsYRCiZYxm6VjxqDPkCUoBl0xNfJovCQynHEox0M8/jzQL4HofzMfayG0L2Ks00c19vFDpbBda32PfX4fZaZVF4ANYCZBPTP89h+PR0xBi2Z8j8CZnQAJbJFSW9bgL2S9DDPTqCgujmM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1566566698; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=VLLZOUkKZy7LUSZZt33Gh+s8WIo71WtnWZoiLOeo2YQ=; b=oL+p4HyOHD8aLOvOmQ2qYGVUvaqyHiBCHLsWHRrSFKEkoOhHEs+Y68vuIdVpljVQmblntm7Pnz7XG9kk/eFMsFCQ8DyI8EIWaCp0P6RJX3jYN2m4OKZgP9OTNz8LPtq5rk8EvkaXlk4cWeRNOrS7HYldJAo7xPY1CLmjRY9+vtA= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 156656669808648.254321814159084; Fri, 23 Aug 2019 06:24:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 66A9C3086246; Fri, 23 Aug 2019 13:24:56 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E0836CE76; Fri, 23 Aug 2019 13:24:54 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 4CCD92551D; Fri, 23 Aug 2019 13:24:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x7NDOnPO032498 for ; Fri, 23 Aug 2019 09:24:49 -0400 Received: by smtp.corp.redhat.com (Postfix) id B4EEF6012A; Fri, 23 Aug 2019 13:24:49 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3ED8E60126 for ; Fri, 23 Aug 2019 13:24:46 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Fri, 23 Aug 2019 15:24:43 +0200 Message-Id: <295cd39aa488e8e94455afeeac5616a789906d3d.1566566683.git.mprivozn@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] storage_driver: Don't crash in storagePoolCreateXML X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Fri, 23 Aug 2019 13:24:57 +0000 (UTC) Content-Type: text/plain; charset="utf-8" In my recent patches I've introduced virStoragePoolObjIsStarting() which is then used to protect storage pool definition when the pool object is locked and unlocked during long running jobs. Well, my patches did not anticipate that @obj can be NULL under 'cleanup' label in storagePoolCreateXML() (for instance when parsing XML fails). This imperfection is causing libvirtd to crash then. Fixes: 13284a6b83 storage_driver: Protect pool def during startup and build Signed-off-by: Michal Privoznik Reviewed-by: Martin Kletzander --- src/storage/storage_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index cd9f14a2c0..30940b5dcf 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -808,7 +808,7 @@ storagePoolCreateXML(virConnectPtr conn, pool =3D virGetStoragePool(conn, def->name, def->uuid, NULL, NULL); =20 cleanup: - if (virStoragePoolObjIsStarting(obj)) { + if (obj && virStoragePoolObjIsStarting(obj)) { if (!virStoragePoolObjIsActive(obj)) virStoragePoolUpdateInactive(obj); virStoragePoolObjSetStarting(obj, false); --=20 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list