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.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html