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!
-Kamal
--
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