From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: Re: [PATCH 2/2] lzo: check for length overrun in
 variable length encoding
Date: Tue, 4 Nov 2014 11:35:13 +0000
Message-ID: <1415100913.11486.31.camel@eu.citrix.com>
References: <5457A3AD020000780004478B@mail.emea.novell.com>
	<5457A71802000078000447AA@mail.emea.novell.com>
	<21592.46976.780608.557136@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1XlcON-0008WL-4F
	for xen-devel@lists.xenproject.org; Tue, 04 Nov 2014 11:35:19 +0000
In-Reply-To: <21592.46976.780608.557136@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
List-Id: xen-devel@lists.xenproject.org

On Tue, 2014-11-04 at 11:24 +0000, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH 2/2] lzo: check for length overrun in variable length encoding"):
> > This fix ensures that we never meet an integer overflow while adding
> > 255 while parsing a variable length encoding. It works differently from
> > commit 504f70b6 ("lzo: properly check for overruns") because instead of
> > ensuring that we don't overrun the input, which is tricky to guarantee
> > due to many assumptions in the code, it simply checks that the cumulated
> > number of 255 read cannot overflow by bounding this number.
> 
> AFAICT this decompressor is exposed to untrusted guest kernel images.

Only in mini-os context, I think. AIUI dom0 hosted libxc uses liblzo2.

Not 100% sure of that, but tools/libxc/Makefile's handling of
xc_dom_decompress_unsafe_lzo1x seems to confirm what I thought.

Aside from that, I presume you are trying to say that the description of
the fix suggests the code would be vulnerable to untrusted input? It
looks to me as if it is infact OK for untrusted input, but perhaps I've
misunderstood what it is doing.

Ian.