* Re: Warning and BUG with btrfs and corrupted image
[not found] ` <cce9e37e0901211815l2195858cob6e68ac8ad93e679@mail.gmail.com>
@ 2009-01-23 8:56 ` Eric Sesterhenn
0 siblings, 0 replies; only message in thread
From: Eric Sesterhenn @ 2009-01-23 8:56 UTC (permalink / raw)
To: Phillip Lougher
Cc: Tom Rini, chris, Jörn Engel, linuxppc-dev, rpurdie, linux-fsdevel
* Phillip Lougher (phil.lougher@gmail.com) wrote:
> On Tue, Jan 20, 2009 at 4:51 PM, Eric Sesterhenn <snakebyte@gmx.de> wrote:
>
> > I already tested squashfs. One issue is basically a problem with
> > the zlib-api for which i just posted a patch here
> > http://marc.info/?t=123212807300003&r=1&w=2
> >
>
> Thanks for testing Squashfs. I've not ignored your emails, but I've
> been busy job hunting, and so have not had time to look into this
> until now.
no problem, made me take a closer look at the issue :-) Hope you were
successfull
> I hardened Squashfs against fsfuzzer back in November 2006 (remember
> the month of kernel bugs, or MOKB, which highlighted a number of
> issues with Squashfs). Your testing has thrown up a regression that I
> inadvertently put in last month!
Thats why I do the fsfuzzer tests for every kernel i test :-)
will you do the "wheter" -> "whether" change for the other patch locally
and push it or do you want me to send a changed version?
> > The other is an overwritten redzone (also reported in this thread
> > http://marc.info/?l=linux-fsdevel&m=123212794425497&w=2)
> > Looks like a length parameter is passed to squashfs_read_data
> > which is bigger than ((msblk->block_size >> msblk->devblksize_log2) +
> > 1), so the kcalloced buffer gets overwritten later.
>
> As part of the mainlining effort I changed Squashfs to allocate
> buffers in 4K page sizes rather than use vmalloced large buffers. As
> far as zlib goes, it means zlib_inflate now decompresses into a
> sequence of 4K buffers rather than one large buffer. What this means
> is zlib_inflate is called repeatedly moving to the next 4K page
> whenever zlib_inflate asks for another buffer (stream.avail_out == 0).
>
> Your testing have thrown up the case where zlib_inflate is asking for
> too many output buffers, i.e. it has returned with Z_OK,
> stream.avail_in !=0 (more input data to be processed), and
> stream.avail_out == 0 (I'd like another output buffer). but it has
> consumed all the output buffers. This isn't checked (the code assumes
> zlib will do the right thing on corrupt data and bomb out). My guess
> is either zlib_inflate is getting confused with corrupt data, or
> fsfuzzer gets lucky sometimes and corrupts the filesystem to point to
> another valid but larger compressed block (i.e. in your test
> filesystems the 4K datablock is being corrupted to point to an 8K
> metadata block).
>
> This ultimately leads to an oops in zlib_inflate where it has been
> passed a bogus or NULL steam.next_out pointer.
>
> I'll create a patch and send it to you if you're happy to test it.
Sure, just throw it in my direction.
Greetings, Eric
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2009-01-23 8:56 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20090113142147.GE16333@alice>
[not found] ` <1231857643.29164.28.camel@think.oraclecorp.com>
[not found] ` <20090113144307.GF16333@alice>
[not found] ` <20090118174035.GG1944@ucw.cz>
[not found] ` <20090120063150.GC5854@alice>
[not found] ` <1232457065.15042.2.camel@think.oraclecorp.com>
[not found] ` <20090120165131.GB21339@alice>
[not found] ` <cce9e37e0901211815l2195858cob6e68ac8ad93e679@mail.gmail.com>
2009-01-23 8:56 ` Warning and BUG with btrfs and corrupted image Eric Sesterhenn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).