From nobody Mon May 6 21:52:48 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 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1529498205776114.29009942668938; Wed, 20 Jun 2018 05:36:45 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3CECF308A950; Wed, 20 Jun 2018 12:36:44 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E85D5201562D; Wed, 20 Jun 2018 12:36:43 +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 449ED1800537; Wed, 20 Jun 2018 12:36:43 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w5KCae41005395 for ; Wed, 20 Jun 2018 08:36:40 -0400 Received: by smtp.corp.redhat.com (Postfix) id 43C035D761; Wed, 20 Jun 2018 12:36:40 +0000 (UTC) Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3AD6F5D75A; Wed, 20 Jun 2018 12:36:37 +0000 (UTC) Received: from huawei.com (unknown [45.249.212.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7ADD1C057F81; Wed, 20 Jun 2018 12:36:35 +0000 (UTC) Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 9E75DCD86A27F; Wed, 20 Jun 2018 16:47:32 +0800 (CST) Received: from localhost (10.175.105.35) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.382.0; Wed, 20 Jun 2018 16:47:25 +0800 From: Weilun Zhu To: Date: Wed, 20 Jun 2018 16:45:27 +0800 Message-ID: <20180620084527.31610-1-zhuweilun@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.105.35] X-CFilter-Loop: Reflected X-Greylist: Delayed for 03:48:59 by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 20 Jun 2018 12:36:36 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 20 Jun 2018 12:36:36 +0000 (UTC) for IP:'45.249.212.32' DOMAIN:'[45.249.212.32]' HELO:'huawei.com' FROM:'zhuweilun@huawei.com' RCPT:'' X-RedHat-Spam-Score: 1.272 * (RDNS_NONE, SPF_HELO_PASS, SPF_PASS) 45.249.212.32 [45.249.212.32] 45.249.212.32 [45.249.212.32] X-Scanned-By: MIMEDefang 2.78 on 10.5.110.32 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Cc: pkrempa@redhat.com, Weilun Zhu , king.wang@huawei.com Subject: [libvirt] [PATCH] qemu: fix msg could be a wild pointer in qemuMonitorIOProcess() 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.84 on 10.5.11.25 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 20 Jun 2018 12:36:44 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" As qemuMonitorJSONIOProcess will call qemuMonitorJSONIOProcessEvent which unlocks the monitor mutex, there is some extreme situation, eg qemu send message to monitor twice in a short time, where the local viriable 'msg' of qemuMonitorIOProcess could be a wild point: 1. qemuMonitorSend() assign mon->msg to parameter 'msg', which is alse a local variable of its caller qemuMonitorJSONCommandWithFd(), cause eventloop to send message to monitor, then wait condition. 2. qemu send message to monitor for the first time immediately. 3. qemuMonitorIOProcess() is called, then wake up the qemuMonitorSend() thread, but the qemuMonitorSend() thread stuck for a while as cpu pressure or some other reasons, which means the qemu monitor is still unlocked. 4. qemu send event message to monitor for the second time, such as RTC_CHANGE event 5. qemuMonitorIOProcess() is called again, the local viriable 'msg' is assigned to mon->msg. 6. qemuMonitorIOProcess() call qemuMonitorJSONIOProcess() to deal with the qemu event. 7. qemuMonitorJSONIOProcess() unlock the qemu monitor in the macro 'QEMU_MONITOR_CALLBACK', then qemuMonitorSend() thread get the mutex and free the mon->msg, assign mon->msg to NULL. Signed-off-by: Weilun Zhu Reviewed-by: Jiri Denemark --- src/qemu/qemu_monitor.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index d6771c1d52..6ed475ede0 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -466,7 +466,11 @@ qemuMonitorIOProcess(qemuMonitorPtr mon) #if DEBUG_IO VIR_DEBUG("Process done %d used %d", (int)mon->bufferOffset, len); #endif - if (msg && msg->finished) + + /* As the monitor mutex was unlocked in qemuMonitorJSONIOProcess() + * while dealing with qemu event, mon->msg could be changed which + * means the above 'msg' may be invalid, thus we use 'mon->msg' here */ + if (mon->msg && mon->msg->finished) virCondBroadcast(&mon->notify); return len; } --=20 2.18.0.rc1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list