When handling speculative page fault we should check for the VMA's
access permission as it is done in handle_mm_fault() or access_error
in x86's fault handler.
Signed-off-by: Laurent Dufour <ldufour@xxxxxxxxxxxxxxxxxx>
---
mm/memory.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 3b28de5838c7..4d9c6331ada1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3756,6 +3756,30 @@ int handle_speculative_fault(struct mm_struct *mm, unsigned long address,
if (address < vma->vm_start || vma->vm_end <= address)
goto unlock;
+ /* XXX Could we handle huge page here ? */
+ if (unlikely(is_vm_hugetlb_page(vma)))
+ goto unlock;
+
+ /*
+ * The three following checks are copied from access_error from
+ * arch/x86/mm/fault.c
+ * XXX they may not be applicable to all architectures
+ */
+ if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
+ flags & FAULT_FLAG_INSTRUCTION,
+ flags & FAULT_FLAG_REMOTE))
+ goto unlock;
+
+ /* This is one is required to check that the VMA has write access set */
+ if (flags & FAULT_FLAG_WRITE) {
+ if (unlikely(!(vma->vm_flags & VM_WRITE)))
+ goto unlock;
+ } else {
+ /* XXX This may not be required */
+ if (unlikely(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))))
+ goto unlock;
+ }
+
/*
* We need to re-validate the VMA after checking the bounds, otherwise
* we might have a false positive on the bounds.
--
2.7.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
