Hi Greg,
This patch fix the CVE-2014-3122, the original patch can not be applied to 3.4 stable tree.
But Ben Hutchings has been backported it to 3.2 stable. The backported patch can be applied to
3.4 stable. So can you cherry-pick it to 3.4 stable tree from 3.2 stable ?
commit id in 3.2 stable: 8e8836abf74a0b227c651cf76466b8d711470a76
---------------------------------------------------------------------
commit 8e8836abf74a0b227c651cf76466b8d711470a76
Author: Vlastimil Babka <vbabka@xxxxxxx>
Date: Mon Apr 7 15:37:50 2014 -0700
mm: try_to_unmap_cluster() should lock_page() before mlocking
commit 57e68e9cd65b4b8eb4045a1e0d0746458502554c upstream.
A BUG_ON(!PageLocked) was triggered in mlock_vma_page() by Sasha Levin
fuzzing with trinity. The call site try_to_unmap_cluster() does not lock
the pages other than its check_page parameter (which is already locked).
The BUG_ON in mlock_vma_page() is not documented and its purpose is
somewhat unclear, but apparently it serializes against page migration,
which could otherwise fail to transfer the PG_mlocked flag. This would
not be fatal, as the page would be eventually encountered again, but
NR_MLOCK accounting would become distorted nevertheless. This patch adds
a comment to the BUG_ON in mlock_vma_page() and munlock_vma_page() to that
effect.
The call site try_to_unmap_cluster() is fixed so that for page !=
check_page, trylock_page() is attempted (to avoid possible deadlocks as we
already have check_page locked) and mlock_vma_page() is performed only
upon success. If the page lock cannot be obtained, the page is left
without PG_mlocked, which is again not a problem in the whole unevictable
memory design.
--
Thanks!
Yijing
--
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