Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAE5jQCfP1Z0oTBz_V0QkFwFqtJgekUMD2HZR=qA2oWxPvZrzsQ@mail.gmail.com>
 <20180603184955.zrowxp4y3ij66y5n@eaf> <20180608152557.GB11958@amd>
 <CAE5jQCeCOK5zoH4KbyP+hiMKp4MpkjJN1efzquoXCfPPXoj9Nw@mail.gmail.com>
 <20180709203455.fbmx45ehrsj6yjzr@eaf> <CAE5jQCd0dD2jcNLGXK0N1g6TOfNfruyTV-7R6Eh1v65bkoqi1g@mail.gmail.com>
 <20180710183839.abazeghy7he4v2ai@eaf>
In-Reply-To: <20180710183839.abazeghy7he4v2ai@eaf>
From:   Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
Date:   Tue, 10 Jul 2018 21:57:27 +0300
Message-ID: <CAE5jQCeidbWG5A8MTk+zo8UtRLCw84pHfJzumgx1JMineK89MA@mail.gmail.com>
Subject: Re: Mounting corrupted HFS+ causes kernel NULL pointer dereference
To:     "Ernesto A. Fernandez" <ernesto.mnd.fernandez@gmail.com>
Cc:     pavel@ucw.cz, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org,
        Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> 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
=D0=B2=D1=82, 10 =D0=B8=D1=8E=D0=BB. 2018 =D0=B3. =D0=B2 21:38, Ernesto A. =
Fern=C3=A1ndez
<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
>
> > =D0=BF=D0=BD, 9 =D0=B8=D1=8E=D0=BB. 2018 =D0=B3. =D0=B2 23:35, Ernesto =
A. Fern=C3=A1ndez
> > <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`, i=
t hangs.
> > >
> > > I just sent you a patch for this final report. Let me know if it work=
s
> > > for you.