Re: Backport Security Fix for CVE-2018-13095 to v4.14

[Dave Chinner <dchinner@redhat.com>]

On Tue, Aug 07, 2018 at 06:39:41PM +0200, Greg KH wrote:
> On Tue, Aug 07, 2018 at 03:17:53PM +0200, Greg KH wrote:
> > On Mon, Aug 06, 2018 at 12:01:20PM +0900, Yuki Machida wrote:
> > > Hi Greg,
> > > 
> > > I conformed that a patch of CVE-2018-13095 not applied at v4.14.60.
> > > Could you please apply a patch for 4.14-stable ?
> > 
> > It does not apply cleanly at all, can you please provide a working
> > backport that you have tested?
> 
> It also breaks the build in 4.17.y, so I've had to drop it there as
> well.

I was going to ask "who tested the backport", but I see that the
backport doesn't even get that far. Blind backports of this sort of
fix is roughly equivalent to playing russian roulette - there's
every chance the additional validation to catch the issue is
completely inappropriate for older kernels and will explode on
users.

> Are you sure this fixes something that you care about?  Why are people
> creating random CVEs for things that no one seems to actually backport?

Glad you said this, Greg, because the recent rash of CVEs raised for
filesystem corruption issues has got well and truly out of hand, not
just for mainline stable backports.

It looks to me like someone thinks that "issue found by fuzzing the
on disk format of a filesystem" equates to an exploitable security
vulnerability. i.e.  they stop thinking at "fuzzing", and they
don't think through to the "need root permissions to mount the
fuzzed filesystem and trigger the bug".

I've ranted a lot about the crappy state of 3rd party filesystem
fuzz testing in recent times, but this rash of CVEs really puts
the icing on the cake....

Cheers,

Dave.

-- 
Dave Chinner
dchinner@redhat.com