linux-kernel - Re: [Stable-review] [patch 35/38] fs/partitions/ldm.c: fix oops caused by corrupted partition table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 07 May 2011 03:24:11 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Timo Warns <warns@...-sense.de>
Cc:	linux-kernel@...r.kernel.org, stable@...nel.org,
	Eugene Teo <eugeneteo@...nel.sg>,
	Richard Russon <rich@...tcap.org>, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, stable-review@...nel.org,
	alan@...rguk.ukuu.org.uk,
	Harvey Harrison <harvey.harrison@...il.com>,
	Greg KH <gregkh@...e.de>
Subject: Re: [Stable-review] [patch 35/38] fs/partitions/ldm.c: fix oops
 caused by corrupted partition table

On Thu, 2011-05-05 at 17:11 -0700, Greg KH wrote:
> 2.6.38-stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> From: Timo Warns <Warns@...-sense.de>
> 
> commit c340b1d640001c8c9ecff74f68fd90422ae2448a upstream.
> 
> The kernel automatically evaluates partition tables of storage devices.
> The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains
> a bug that causes a kernel oops on certain corrupted LDM partitions.
> A kernel subsystem seems to crash, because, after the oops, the kernel no
> longer recognizes newly connected storage devices.
> 
> The patch validates the value of vblk_size.

I don't think this actually fixes the vulnerability, and I don't think
this code works at all.

> [akpm@...ux-foundation.org: coding-style fixes]
> Signed-off-by: Timo Warns <warns@...-sense.de>
> Cc: Eugene Teo <eugeneteo@...nel.sg>
> Cc: Harvey Harrison <harvey.harrison@...il.com>
> Cc: Richard Russon <rich@...tcap.org>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> 
> ---
>  fs/partitions/ldm.c |   16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> --- a/fs/partitions/ldm.c
> +++ b/fs/partitions/ldm.c
> @@ -1299,6 +1299,11 @@ static bool ldm_frag_add (const u8 *data
>  
>  	BUG_ON (!data || !frags);
>  
> +	if (size < 2 * VBLK_SIZE_HEAD) {
> +		ldm_error("Value of size is to small.");
> +		return false;
> +	}
> +
>  	group = get_unaligned_be32(data + 0x08);
>  	rec   = get_unaligned_be16(data + 0x0C);
>  	num   = get_unaligned_be16(data + 0x0E);
> @@ -1306,6 +1311,10 @@ static bool ldm_frag_add (const u8 *data
>  		ldm_error ("A VBLK claims to have %d parts.", num);
>  		return false;
>  	}
> +	if (rec >= num) {
> +		ldm_error("REC value (%d) exceeds NUM value (%d)", rec, num);
> +		return false;
> +	}

This is fine for the first fragment we find, when we allocate memory
based on 'num'.  However, when we add another fragment, we need to
compare with f->num.  So there still seems to be the possibility of a
buffer overflow.

>  	list_for_each (item, frags) {
>  		f = list_entry (item, struct frag, list);
> @@ -1334,10 +1343,9 @@ found:
>  
>  	f->map |= (1 << rec);
>  
> -	if (num > 0) {
> -		data += VBLK_SIZE_HEAD;
> -		size -= VBLK_SIZE_HEAD;
> -	}
> +	data += VBLK_SIZE_HEAD;
> +	size -= VBLK_SIZE_HEAD;
> +
>
>  	memcpy (f->data+rec*(size-VBLK_SIZE_HEAD)+VBLK_SIZE_HEAD, data, size);
> 
>  	return true;

The offset used for the destination means that the first VBLK_SIZE_HEAD
bytes of f->data are never initialised!

I suspect (without any knowledge of LDM) that the intent was to use the
header from the first fragment and drop it from the subsequent
fragments, like this:

	if (rec == 0)
		memcpy(f->data, data, VBLK_SIZE_HEAD);
	data += VBLK_SIZE_HEAD;
	size -= VBLK_SIZE_HEAD;
	memcpy(f->data + VBLK_SIZE_HEAD + rec * size, data, size);

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)