Messages in this thread | | | From | Jann Horn <> | Subject | [PATCH 0/2] fix vma->anon_vma check for per-VMA locking; fix anon_vma memory ordering | Date | Wed, 26 Jul 2023 23:41:01 +0200 |
| |
Hi!
Patch 1 here is a straightforward fix for a race in per-VMA locking code that can lead to use-after-free; I hope we can get this one into mainline and stable quickly.
Patch 2 is a fix for what I believe is a longstanding memory ordering issue in how vma->anon_vma is used across the MM subsystem; I expect that this one will have to go through a few iterations of review and potentially rewrites, because memory ordering is tricky. (If someone else wants to take over patch 2, I would be very happy.)
These patches don't really belong together all that much, I'm just sending them as a series because they'd otherwise conflict.
I am CCing:
- Suren because patch 1 touches his code - Matthew Wilcox because he is also currently working on per-VMA locking stuff - all the maintainers/reviewers for the Kernel Memory Consistency Model so they can help figure out the READ_ONCE() vs smp_load_acquire() thing - people involved in the previous discussion on the security list
Jann Horn (2): mm: lock_vma_under_rcu() must check vma->anon_vma under vma lock mm: Fix anon_vma memory ordering
include/linux/rmap.h | 15 ++++++++++++++- mm/huge_memory.c | 4 +++- mm/khugepaged.c | 2 +- mm/ksm.c | 16 +++++++++++----- mm/memory.c | 32 ++++++++++++++++++++------------ mm/mmap.c | 13 ++++++++++--- mm/rmap.c | 6 ++++-- mm/swapfile.c | 3 ++- 8 files changed, 65 insertions(+), 26 deletions(-)
base-commit: 20ea1e7d13c1b544fe67c4a8dc3943bb1ab33e6f -- 2.41.0.487.g6d72f3e995-goog
| |