Thread (181 messages) 181 messages, 12 authors, 2023-11-22

Re: [PATCH 09/41] mm: rcu safe VMA freeing

From: Suren Baghdasaryan <surenb@google.com>
Date: 2023-01-18 02:16:34
Also in: linux-arm-kernel, linux-mm, lkml

On Tue, Jan 17, 2023 at 6:25 AM Michal Hocko [off-list ref] wrote:
On Mon 09-01-23 12:53:04, Suren Baghdasaryan wrote:
[...]
quoted
 void vm_area_free(struct vm_area_struct *vma)
 {
      free_anon_vma_name(vma);
+#ifdef CONFIG_PER_VMA_LOCK
+     call_rcu(&vma->vm_rcu, __vm_area_free);
+#else
      kmem_cache_free(vm_area_cachep, vma);
+#endif
Is it safe to have vma with already freed vma_name? I suspect this is
safe because of mmap_lock but is there any reason to split the freeing
process and have this potential UAF lurking?
It should be safe because VMA is either locked or has been isolated
while locked, so no page fault handlers should have access to it. But
you are right, moving free_anon_vma_name() into __vm_area_free() does
seem safer. Will make the change in the next rev.
quoted
 }

 static void account_kernel_stack(struct task_struct *tsk, int account)
--
2.39.0
--
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help