linux-kernel - Re: Re : vm: weird behaviour when munmapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 17 Nov 2006 14:48:50 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	moreau francis <francis_moreau2000@...oo.fr>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Re : vm: weird behaviour when munmapping

On Fri, 2006-11-17 at 13:43 +0000, moreau francis wrote:
> Peter Zijlstra wrote:
> > On Fri, 2006-11-17 at 12:50 +0000, moreau francis wrote:
> >>
> >> lower vma: 0x2aaae000 -> 0x2aaaf000
> >> upper vma: 0x2aaaf000 -> 0x2aab2000
> > 
> > that is the remaining VMA, not the new one; we trigger this code:
> > 
> >     /* Does it split the last one? */
> >     last = find_vma(mm, end);
> >     if (last && end > last->vm_start) {
> >         int error = split_vma(mm, last, end, 1);
> >         if (error)
> >             return error;
> >     }
> > 
> > So, since its the last VMA that needs to be split (there is only one),
> > the new VMA is constructed before the old one. Like so:
> > 
> >   AAAAAAAAAAAAAAAAAAAAA
> >   BBBBAAAAAAAAAAAAAAAAA
> > 
> > Then you proceed closing, in this case the new one: B.
> 
> Sorry but I don't understand why B is said to be the new one. OK
> I can see why from the bit of code you pointed out but from a
> logical point of view (ok maybe be me only) I'm unmapping 'BBBB'
> segment, so 'BBBB' is going to be destroyed and therefore A is
> the new one. Thereferore I would expect close(B), open(A)...
> 
> no ?

No indeed. You seem confused with remaining and new. 

It has one VMA (A) it needs to split that into two pieces, it happens to
do it like (B,A') where A' is the old VMA object with new a start
address, and B is a new VMA object.

If you'd unmapped the tail end of your region you'd then see a close of
A' but you happen to unmap the head so you'll see B closed.

vm_ops->open() is called on new VMA objects, in this scenario B is the
only new object created. A -> A' is not creating a new object just
modifying an old one.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/