From nobody Mon Feb 9 00:56:22 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 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=1623855991; cv=none; d=zohomail.com; s=zohoarc; b=Xh6Sug/ZRPXXUhW9P+zJ7zlmlxailmwaQJflaMPhSXEa/Bt+757aFZAve0qcgkYHg638pJkc1dtjkGXK8gB1d1FWT3ds3eyYr61ebctuHTB2qp0+L3Ottst1VkIbX43+NzwWe2SAX56hP9fGeWngQUuB5gr7caJSdowwesjFLvw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1623855991; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=J/TZ4WQ/NKOfpnmG2RxTR03CvGdnvWhzI/If011ngx4=; b=X73+Q8WDapODPYi12Sx+m5uTOOwi5FLKkBz+soRwUlekdkMEwc8wJcGnHs491PUPdk90njI7mNDVgEpL72wr/GuTKak0+QP32RTF9HncccDmfAxKOvnA6WAyZsCIAfspIDxPrQIY3Exs9YmPbFPlC+IdogT2nQpv+DFEDx8kjZQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.zohomail.com with SMTPS id 1623855991552484.3567763244514; Wed, 16 Jun 2021 08:06:31 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-223-stLlBAtYNiSZvaAsr-nfqQ-1; Wed, 16 Jun 2021 11:05:56 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 631F010C79E0; Wed, 16 Jun 2021 15:05:50 +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 3A4AE10074E1; Wed, 16 Jun 2021 15:05:50 +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 F000646F82; Wed, 16 Jun 2021 15:05:49 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 15GF5md3012851 for ; Wed, 16 Jun 2021 11:05:48 -0400 Received: by smtp.corp.redhat.com (Postfix) id A80695D9E3; Wed, 16 Jun 2021 15:05:48 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.40.208.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A1FA5D9E2 for ; Wed, 16 Jun 2021 15:05:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623855957; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=J/TZ4WQ/NKOfpnmG2RxTR03CvGdnvWhzI/If011ngx4=; b=g14Gey1MfME8lZ6CYnRUD0VOMf2cIQHmCz2nHKOCeWUdlH5KzDL2epn2t5lSsEeKefGdC1 +VA1ltf93XOqkpY6N+A3547zknFFvhnEQU8ZP1shuhlNQc500yQCyZb7mZ07YGfvqzG5am 8C9DZN+CZ03ZjL+70xFNt4RJ5shP04s= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623855990; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=J/TZ4WQ/NKOfpnmG2RxTR03CvGdnvWhzI/If011ngx4=; b=eZLopYSnDJQwczux2Ja9zfUKE9G0poIy5Gd8aAPeHWJfOwTqmZCj73fvV0KS4DphkfwhWe 3V1iJHcT8ucVWM/uUVc820R2/I2q+rhGFOexnZsTimKkJoeihoFMa8kUQyHXZX/cs3TP5+ arjsKgkueaITNFXUg3rdEF4CY3rS2Vw= X-MC-Unique: stLlBAtYNiSZvaAsr-nfqQ-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 4/7] qemuSnapshotPrepareDiskExternal: Enforce match between snapshot type and existing file type Date: Wed, 16 Jun 2021 17:05:34 +0200 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-loop: libvir-list@redhat.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) (identity @redhat.com) Content-Type: text/plain; charset="utf-8" The code executed later when creating a snapshot makes all decisions based on the configured type rather than the actual type of the existing file, while the check whether the file exists is based solely on the on-disk type. Since a block device is allowed to exist even when not reusing existing files in contrast to regular files this creates a potential for a block device to squeak past the check but then be influenced by other code executed later. Specifically this is a problem when creating a snapshot with the following XML: If the snapshot creation fails, '/dev/sdb' will be removed because it's considered to be a regular file by the cleanup code. Add a check that will force that the configured type matches the on-disk state. Additional supporting reason is that qemu stopped to accept block devices with the 'file' backend, thus the above configuration will not work any more. This allows us to fail sooner. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D1972145 Signed-off-by: Peter Krempa --- src/qemu/qemu_snapshot.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index f06d0ada38..96c43f69e7 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -598,6 +598,15 @@ qemuSnapshotPrepareDiskExternal(virDomainObj *vm, } } } else { + /* at this point VIR_STORAGE_TYPE_DIR was already rejected */ + if ((snapdisk->src->type =3D=3D VIR_STORAGE_TYPE_BLOCK && !S_I= SBLK(st.st_mode)) || + (snapdisk->src->type =3D=3D VIR_STORAGE_TYPE_FILE && !S_IS= REG(st.st_mode))) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("mismatch between configured type for sna= pshot disk '%s' and the type of existing file '%s'"), + snapdisk->name, snapdisk->src->path); + return -1; + } + if (!S_ISBLK(st.st_mode) && st.st_size && !reuse) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("external snapshot file for disk %s alrea= dy " --=20 2.31.1