linux-kernel - Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAE5jQCeidbWG5A8MTk+zo8UtRLCw84pHfJzumgx1JMineK89MA@mail.gmail.com>
Date:   Tue, 10 Jul 2018 21:57:27 +0300
From:   Anatoly Trosinenko <anatoly.trosinenko@...il.com>
To:     "Ernesto A. Fernandez" <ernesto.mnd.fernandez@...il.com>
Cc:     pavel@....cz, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference

> 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.

I just thought that deadlocking a single thread is not much worse than
further damaging already damaged FS and is not very dangerous (since
it's not a NULL dereference or something like this). If it is or only
malicious image can probably be damaged this way then I have no
objections or further requests, so please excuse me for unclear
wordings.

Thanks,
Anatoly
вт, 10 июл. 2018 г. в 21:38, Ernesto A. Fernández
<ernesto.mnd.fernandez@...il.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@...il.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.