On Wed, 2014-07-30 at 12:43 -0700, Hugh Dickins wrote:
> On Tue, 29 Jul 2014, Kamal Mostafa wrote:
> > On Wed, 2014-07-23 at 18:17 -0700, Hugh Dickins wrote:
> > > Hi,
> > >
> > > Commit 8e205f779d1443a94b5ae81aa359cb535dd3021e
> > > ("shmem: fix faulting into a hole, not taking i_mutex")
> > >
> > > and commit b1a366500bd537b50c3aad26dc7df083ec03a448
> > > ("shmem: fix splicing from a hole while it's punched")
> > >
> > > have now gone into Linus's tree for 3.16, marked for stable 3.1+;
> > > but the first of those depends upon (and fixes) an earlier 3.16 commit,
> > > not marked for stable at the time because I didn't think it mattered
> > > much beyond Trinity fuzzing - but became more significant once it was
> > > tagged with CVE-2014-4171:
> > >
> > > commit f00cdc6df7d7cfcabb5b740911e6788cb0802bdb
> > > ("shmem: fix faulting into a hole while it's punched")
> > >
> > > Please add f00cdc6df7d7 to your stable queues just before 8e205f779d14
> > > when you're ready, then I won't get quite so many "failed to apply"
> > > mails in a few days time!
> > >
> > > I have already checked application to the kernel.org stable trees:
> > > f00cdc6df7d7 and 8e205f779d14 should be good as is back to 3.10.49;
> > > but b1a366500bd5 gets a reject on 3.14.13, so I'll need to supply
> > > custom versions prepared for that and earlier releases - as I must
> > > for all three on 3.4.99 and 3.2.61 (anything before 3.5 involves
> > > more partial backporting).
> > >
> > > I'm assuming that it's easiest if I wait for your "failed to apply"
> > > mails, and then respond to each with the version I've prepared: if
> > > you would prefer me to send them in advance, please let me know.
> > >
> > > (As Vlastimil observed, there's a danger in fixing up the reject
> > > in b1a366500bd5: when the first hunk is rejected, the second and
> > > third get applied in the wrong place, so better use my versions.)
> > >
> > > I've not actually built the Canonical trees, but a glance at them
> > > suggests they will all be good with the 3.10.49 one for b1a366500bd5.
> > >
> > > Thanks,
> > > Hugh
> > >
> >
> > All three queued up for 3.8-stable and 3.13-stable. Thanks very much
> > Hugh!
>
> Thanks guys, I've checked what Kamal and Luis and Jiri posted today,
> and they're all fine.
>
> I think that just leaves Ben's 3.2.62 to come: Ben, when you're ready,
> please just use the three that Greg put in 3.4.100. The only problem
> with those is obvious: where the first removes vmtruncate_range() from
> mm/truncate.c, in 3.2 it's at end of file, but by 3.4 another function
> had been added after it.
Thanks, I'm just preparing 3.2.62-rc1 now.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
Attachment:
signature.asc
Description: This is a digitally signed message part