Re: [PATCH 0/3] mm: Fix misuse of parent anon_vma in dup_mmap path

["Li Xinhai" <lixinhai.lxh@gmail.com>]

On 2020-04-20 at 20:06 Michal Hocko wrote:
>On Mon 10-02-20 10:15:53, Li Xinhai wrote:
>[...]
>> >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.
>
>I am still not completely clear on the user effect. Does this allow an
>adversary to generate too long anon_vma chains that wouldn't normally
>happen or some other nasties that would make backporting to older
>kernels really necessary? 
It allows for generating long anon_vma chain by keep forking child process, although
the memory consumed for anon_vma structure wouldn't increase accordingly. I don't
see other impact of those two issues. 

> Because from my current understanding it would
>only make WIPEONFORK vmas rmap walks less efficient. Or is there any
>other functional issue? 
#1 issue is for case WIPEONFORK, #2 issue for all other cases of anonymous VMA dup
(i.e., when parent vmas is currently sharing anon_vma among themself, child vma will
share its parent vma's anon_vma).
Both cause inefficient rmap walking, no other functional issues.

In my understanding, this patchset can be backported to stable kernel. E.g., If someone mmap
a big vm area, and split that vma to several adjacent vmas(e.g., by mprotect), then
sharing anon_vma at parent process level is achivied. After that, begin fork child, maybe
choose to keep forking child from the top parent process, or let child process keep forking
its own child. At this moment, sharing anon_vma among children and parent is achieved
and has long chain.

>--
>Michal Hocko
>SUSE Labs