public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>,
	Jan Kara <jack@suse.cz>,
	"HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com>,
	stable <stable@vger.kernel.org>
Subject: Re: Security fixes for 4.4
Date: Fri, 17 Nov 2017 09:10:29 +0100	[thread overview]
Message-ID: <20171117081029.GC10671@kroah.com> (raw)
In-Reply-To: <20171116220742.qjekxmefiukqpx2t@thunk.org>

On Thu, Nov 16, 2017 at 05:07:42PM -0500, Theodore Ts'o wrote:
> On Thu, Nov 16, 2017 at 12:29:56PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Nov 15, 2017 at 09:10:46PM +0000, Ben Hutchings wrote:
> > > Please apply the attached backported patches to 4.4-stable.  The
> > > upstream commits are:
> > > 
> > > 06bd3c36a733 ext4: fix data exposure after a crash
> > 
> > This patch did not apply, and when I worked at it by hand to apply, it
> > then broke the build with:
> > 	fs/ext4/inode.c: In function ‘ext4_map_blocks’:
> > fs/ext4/inode.c:669:17: error: ‘EXT4_GET_BLOCKS_ZERO’ undeclared (first use in this function); did you mean ‘EXT4_GET_BLOCKS_PRE_IO’?
> >        !(flags & EXT4_GET_BLOCKS_ZERO) &&
> >                  ^~~~~~~~~~~~~~~~~~~~
> > 
> > As Ted didn't provide this on the list of ext4 patches to backport to
> > 4.4 in the past, I'm a bit hesitant to take this now.  Are you sure it
> > is needed?
> 
> As Greg noted, EXT4_GET_BLOCKS_ZERO is not in the Linux 4.4 kernel.
> To make this works requires at least three pre-requisite commits:
> 
> 2dcba4781fa3: ext4: get rid of EXT4_GET_BLOCKS_NO_LOCK flag
> 53085fac02d1: ext4: provide ext4_issue_zeroout()
> c86d8db33a92: ext4: implement allocation of pre-zeroed blocks
> 
> I do *not* know if backporting these patches plus 06bd3c36a733 will
> result in a kernel that has no regressions.  I'm doing a build and
> will run a regression test run.  But it's a background low-priority
> work item, and if I see any regressions when I run the regression
> tests, I reserve the right not to decide not to care about trying to
> fix this particular backport.
> 
> Personally, I don't think the fix is *that* important.  If you care
> about this kind of expore of stale data after a crash (which only
> happens if you get unlucky and/or your storage device reorders writes
> very aggressively), then you should care about all of the zero-days
> that result in privilege escalation that *don't* get backported to
> 4.4, and consider using something a lot more recent.  Say, 4.9 or
> preferably 4.14?  :-)

Well, some people are stuck on 4.4 kernels for the obviously shitty
reasons (SoC crap), so that option is not always available to them.  So
if you do happen to be running these backports through some testing, I
would appreciate the results :)

thanks,

greg k-h

  reply	other threads:[~2017-11-17  8:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 21:10 Security fixes for 4.4 Ben Hutchings
2017-11-16 11:29 ` Greg Kroah-Hartman
2017-11-16 22:07   ` Theodore Ts'o
2017-11-17  8:10     ` Greg Kroah-Hartman [this message]
2017-11-17 13:30     ` Ben Hutchings
2017-11-20 14:02       ` Jan Kara
2017-11-17 12:06   ` Ben Hutchings
2017-11-17 12:25     ` Greg Kroah-Hartman
2017-11-16 11:31 ` Greg Kroah-Hartman
2017-11-16 11:32   ` Paolo Bonzini
2017-11-16 13:28     ` Greg Kroah-Hartman
2017-11-16 11:33 ` Greg Kroah-Hartman
2017-11-16 11:33 ` Greg Kroah-Hartman
2017-11-16 11:34 ` Greg Kroah-Hartman
2017-11-19 10:18 ` Greg Kroah-Hartman
  -- strict thread matches above, loose matches on Subject: below --
2018-12-13 18:51 Ben Hutchings
2018-12-13 18:52 ` Ben Hutchings
2018-12-13 19:13 ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171117081029.GC10671@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Weller.Huang@cn.bosch.com \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=jack@suse.cz \
    --cc=stable@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox