From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqJvh-0000HK-Nx for qemu-devel@nongnu.org; Mon, 17 Nov 2014 05:53:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqJvb-0005ev-Io for qemu-devel@nongnu.org; Mon, 17 Nov 2014 05:53:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqJvb-0005ep-9T for qemu-devel@nongnu.org; Mon, 17 Nov 2014 05:53:03 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAHAr272007116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 17 Nov 2014 05:53:02 -0500 Date: Mon, 17 Nov 2014 12:52:59 +0200 From: "Michael S. Tsirkin" Message-ID: <20141117105259.GA20683@redhat.com> References: <1415785203-26938-1-git-send-email-mst@redhat.com> <20141117063638.GB10401@grmbl.mre> <20141117103257.GI20133@redhat.com> <20141117103858.GC24729@grmbl.mre> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141117103858.GC24729@grmbl.mre> Subject: Re: [Qemu-devel] [PATCH 0/4] migration: fix CVE-2014-7840 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: quintela@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com On Mon, Nov 17, 2014 at 04:08:58PM +0530, Amit Shah wrote: > On (Mon) 17 Nov 2014 [12:32:57], Michael S. Tsirkin wrote: > > On Mon, Nov 17, 2014 at 12:06:38PM +0530, Amit Shah wrote: > > > On (Wed) 12 Nov 2014 [11:44:35], Michael S. Tsirkin wrote: > > > > This patchset fixes CVE-2014-7840: invalid > > > > migration stream can cause arbitrary qemu memory > > > > overwrite. > > > > First patch includes the minimal fix for the issue. > > > > Follow-up patches on top add extra checking to reduce the > > > > chance this kind of bug recurs. > > > > > > > > Note: these are already (tentatively-pending review) > > > > queued in my tree, so only review/ack > > > > is necessary. > > > > > > Why not let this go in via the migration tree? > > > > Well I Cc'd Juan and David, so if they had a problem with this, I expect > > they'd complain. David acked so I assume it's ok. Since I wasted time > > testing this and have it on my tree already, might as well just merge. > > IMO asking as a courtesy would've been better than just stating it. Right, thanks for reminding me. BTW, there is actually a good reason to special-case it: it's a CVE fix, which I handle. So they stay on my private queue and are passed to vendors so vendors can fix downstreams, until making fix public is cleared with all reporters and vendors. After reporting is cleared, I try to collect acks but don't normally route patches through separate queues - that would make it harder to track the status which we need for CVEs. I guess this specific one actually is well contained, so it could go in through a specific tree if it had to. In fact, it is still possible if Juan says he prefers it so: I only expect to send pull request around tomorrow or the day after that. > > Which reminds me: we really should have someone in MAINTAINERS > > for migration-related files. > > There is, since last week. > > > Amit That's good. I see Juan is listed there now, so all's well. -- MST