Eric Sesterhenn wrote:
I already reported a similar issue to Phillip but got no reply (lost in spam?), so I duplicate it here:
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. I've replied to the btrfs corrupted filesystem thread, but for people not following that I've copied it here. 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! 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. Phillip -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
