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? Because from my current understanding it would only make WIPEONFORK vmas rmap walks less efficient. Or is there any other functional issue? -- Michal Hocko SUSE Labs
