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@xxxxxxxxxx
