WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] blktap kernel module accessing freed memory?
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 17 Mar 2009 14:22:41 +0000
Delivery-date: Tue, 17 Mar 2009 07:22:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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
do_munmap()).

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).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>