On Fri, 2015-09-11 at 12:04 +0900, sf...@users.sourceforge.net wrote: > Ben Hutchings: > > I don't see any need for holding a reference to vma->vm_prfile here. > > > > There is also a similar bug in madvise_remove() which I can trigger by > > calling madvise(..., MADV_REMOVE) in parallel with another thread that > > does mmap() and munmap() of the same address range. > > Did you test mmap()/munmap() using the same opened-file-object with the > original mmap/madvise?
Yes. > As I wrote in > http://www.openwall.com/lists/oss-security/2015/09/10/4 > I still think to get/put(vm_prfile) is necessary. I think it doesn't matter when the last reference is from a running system call and not a vma. There is no way that the process could use the aufs file structure at this point. > > This bug has some security impact (at least a minor DoS, but possible > > privilege escalation) so I'm going to request a CVE ID for it. > > Would you explain the possible scenario of the privilege escalation? In general: while one task is about to use freed memory, another task can race to reallocate that memory, and it may be possible for an attacker to arrange that the initialisation by the second task will cause the first task to jump to attacker-controlled code. I think it's unlikely in this case because there is a specific slab cache for struct vm_area_struct and so it can't be aliased with some other type, but it's still a possibility. Ben. ------------------------------------------------------------------------------
