[LU-4161] e2image -I has malloc corruption in write_bitmaps

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Trivial
• Reporter: Kit Westneat (Inactive)
• Assignee: Niu Yawei (Inactive)
• Resolution: Fixed

Environment

Centos 5

• Severity: 3

Description

For LU-3542 I was trying to use e2image to get the sparse image of some OSTs, but was still having issues with the size of the files. I tried moving the sparse image to another machine and expanding it on a loopback device, but got malloc corruption when using -I. I tracked it down to a buffer overflow in write_bitmaps:

...
		retval = io_channel_alloc_buf(fs->io, 0, &block_buf);
		if (retval)
			goto errout;
		memset(block_buf, 0xff, fs->blocksize);
...

Basically, the io->block_size is 1024, so alloc_buf creates a 1k buffer but then memset writes out 4k. I changed it to:

                retval = io_channel_alloc_buf(fs->io, fs->blocksize / fs->io->block_size, &block_buf);

e2image -I still doesn't work for me for some reason, but it doesn't hit the malloc

Comments

[Kit Westneat (Inactive)]

I got it working I think, there were corresponding changes that needed to be made to the calls to io_channel_write_blk64.

I'll try to get a patch together.

[Peter Jones]

That's great Kit!

Niu

Could you please help out with this one?

Thanks

Peter

[Kit Westneat (Inactive)]

I spoke too soon, I still am having issues with -I correctly writing out an fs image.

[Andreas Dilger]

I suspect the first problem is that e2image incorrectly thinks the blocksize is 1024, when it should really be 4096 to match the filesystem image?

[Kit Westneat (Inactive)]

it looks like ext2fs_rewrite_to_io is resetting the fs->io to be the IO channel of the new device, but that is still using the default blocksize of 1k. Should ext2fs_rewrite_to_io copy the block size?

[Andreas Dilger]

I can't think of any good reason that the blocksize would not be the same...

[Kit Westneat (Inactive)]

Ok, I pushed a patch:
http://review.whamcloud.com/#/c/8095

[Andreas Dilger]

I saw in the patch comment that you are using "e2image -I image" to install the image on a new device. I was using "e2image -Q /dev/XXX image.qcow" to generate a packed image, and then "e2image -r image.qcow image.raw" to convert it into a raw image for testing. I didn't use the "-I" image, so didn't see any problems.

[Shuichi Ihara (Inactive)]

The pathes should be landed in master of e2fsprogs. So, we can close it.