On 2020-02-10 at 08:52 Andrew Morton wrote: >On Sat, 8 Feb 2020 08:35:25 +0000 Li Xinhai <lixinhai.lxh@xxxxxxxxx> wrote: > >> This patchset fix the misuse of parenet anon_vma, which mainly caused by >> child vma's vm_next and vm_prev are left same as its parent after >> duplicate vma. Finally, code reached parent vma's neighbor by referring >> pointer of child vma and executed wrong logic. >> >> The first two patches fix relevant issues, and the third patch sets vm_next >> and vm_prev to NULL when duplicate vma to prevent potential misuse in future. > >What are the runtime effects of this bug? How is the bug triggered? Effects of the first one is that causes ramp code to check both parent and child's page table, although a page couldn't be mapped by both parent and child, because child vma has WIPEONFORK so all pages mapped by child are 'new' and not relevant to parent. Effects of the second one is that the relationship of anon_vma of parent and child are totally convoluted. It would cause 'son', 'grandson', ..., etc, to share 'parent' anon_vma, which disobey the design rule of reusing anon_vma (the rule to be followed is that reusing should among vma of same process, and vma should not gone through fork). So, both issues should cause unnecessary rmap walking and have unexpected complexity. These two issues would not be directly visible, I used debugging code to check the anon_vma pointers of parent and child when inspecting the suspicious implementation of issue #2, then find the problem.
