From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:33406 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726574AbeHHA7x (ORCPT ); Tue, 7 Aug 2018 20:59:53 -0400 Date: Wed, 8 Aug 2018 08:43:11 +1000 From: Dave Chinner To: Greg KH Cc: Yuki Machida , stable@vger.kernel.org, wen.xu@gatech.edu, darrick.wong@oracle.com Subject: Re: Backport Security Fix for CVE-2018-13095 to v4.14 Message-ID: <20180807224311.GB20351@rh> References: <20180807131753.GD1904@kroah.com> <20180807163941.GA2785@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180807163941.GA2785@kroah.com> Sender: stable-owner@vger.kernel.org List-ID: 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