Date: Sat, 23 Aug 2003 20:42:01 -0700
From: Andrew Morton <akpm@osdl.org>
To: dan@merillat.org
Cc: linux-kernel@vger.kernel.org, harik@chaos.ao.net,
       Oleg Drokin <green@namesys.com>
Subject: Re: Reiserfs kernel-crashing bug in 2.4.20 (and UML)
Message-Id: <20030823204201.06c706c1.akpm@osdl.org>
In-Reply-To: <4878.24.165.250.16.1061688482.squirrel@mail.merillat.org>
References: <4878.24.165.250.16.1061688482.squirrel@mail.merillat.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1253
Lines: 34

dan@merillat.org wrote:
>
>  Let's get this out of the way first: I KNOW IT'S A HARDWARE BUG.  My
>  system wrote corrupted data to the drive.  I've already recovered the
>  partition but I have a dd'd copy around to figure this out.
> 
>  With that out of the way:
> 
>  I can reliably insta-reboot my kernel or cause user-mode-linux to crash
>  out when doing a directory lookup in one corrupted directory.
> 
>  The catch is, (and there's always a catch) neither oopses.  real kernel on
>  real hardware just flashes the screen and reboots, user-mode-linux just
>  drops back to the host's shell prompt.
> 
>  Here's what I've found using UML on it:
> 
>  The directory is one block, but we're reading data 100+k into it.  Perhaps
>  a sanity check that we're actually within the buffer we want to be?

You're absolutely right.  Filesystem drivers should try hard to not crash
the box when fed random crap.

> +		if (d_reclen < 0)
> +			return -EIO;

It needs to be checked for some upper bound as well.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/