This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] blktap kernel module accessing freed memory?

To: <julian.chesterfield@xxxxxxxxxxxx>, "Andrew Warfield" <andy@xxxxxxxxx>,<julian@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] blktap kernel module accessing freed memory?
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 19 Mar 2009 09:08:58 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 19 Mar 2009 02:08:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49BFC041.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <49BFC041.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> "Jan Beulich" <jbeulich@xxxxxxxxxx> 17.03.09 15:22 >>>
>blktap_release() makes use of the vma stored in blktap_mmap(). This vma,
>however, should be invalid by the time control reaches blktap_release(),
>as it gets freed from release_vma() (in the context of either exit_mm() or
>While it seems this was always the case (and always wrong), is seems this
>is becoming more of a problem with the mmap_sem locking additions of c/s
>719, as that change results in more uses of the possibly no longer initialized
>data (we just had a report of info->vma->vm_mm being NULL).
>The reason I'm not directly submitting a patch for this is that I'm uncertain
>of the purpose of this extra call to zap_page_range(): While it could be
>moved into a to-be-created vm_operations.close actor, it would seem
>redundant to do so, since unmap_vmas() already takes care of removing
>the mappings for the vma in question.
>Regardless of that, the kfree(info->vma->vm_private_data) must be
>moved into this to-be-created vm_operations.close actor imo. And in
>order to not risk using info->vma past that actor, it might be a good idea
>to also clear out info->vma there (namely for fast_flush_area(), which
>already checks whether that pointer is non-NULL).

You seem to be the original authors of blktap, so I'm hoping that you could
comment on this.

Additionally I'm attaching a tentative patch (against 2.6.27.x), provided
the analysis above is correct.

Thanks a lot,

Attachment: xen-blktap-vma-close.patch
Description: Text document

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>