Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

["Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>]

On Tue, Jul 10, 2018 at 08:28:37PM +0300, Anatoly Trosinenko wrote:
> Thank you,
> 
> When applied this single patch on v4.18-rc4 and performed "echo >
> /mnt/xyz" on hfsplus_16mb_hang image, I get about 14 pairs of lines
> 
> hfsplus: unable to mark blocks free: error -5
> hfsplus: can't free extent
> 
> Then `echo` exits with "No space left on device" error.

Truncation does not return error codes in hfsplus, hence this weird "No
space left" that comes from somewhere else. This should be fixed, but
it's not as big an issue as the deadlock. Filesystems usually don't need
to worry about protecting a crafted image from acting weird and causing
damage to itself.

>Then it
> permits to perform `rm /mnt/xyz` and on `echo > /mnt/1` it responds
> with no space left on device (but file *is* created and is cattable).
> I don't know what is safer, but now it doesn't deadlock. :) Maybe it
> is even worth to remount FS r/o, I don't know. (Please excuse me for
> speculations)

It's not strange that the /mnt/1 file could be created but not written
to, since the first operation doesn't usually require allocating blocks.

> 
> Thanks,
> Anatoly

OK, I'll take a look at the truncation error codes as soon as I'm done
with the other deadlocks I found. It could take a while.

Thanks for the testing.
Ernest

> пн, 9 июл. 2018 г. в 23:35, Ernesto A. Fernández
> <ernesto.mnd.fernandez@gmail.com>:
> >
> > On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote:
> > > And when I mount hfsplus_16mb_hang and perform `echo > /mnt/xyz`, it hangs.
> >
> > I just sent you a patch for this final report. Let me know if it works
> > for you.