[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v6 06/11] softmmu/memory: enable automatic deallocation of memory regions
- To: Akihiko Odaki <akihiko.odaki@xxxxxxxxxx>, Marc-André Lureau <marcandre.lureau@xxxxxxxxx>, Philippe Mathieu-Daudé <philmd@xxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx>, "Michael S . Tsirkin" <mst@xxxxxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Antonio Caggiano <quic_acaggian@xxxxxxxxxxx>, "Dr . David Alan Gilbert" <dgilbert@xxxxxxxxxx>, Robert Beckett <bob.beckett@xxxxxxxxxxxxx>, Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx>, Gert Wollny <gert.wollny@xxxxxxxxxxxxx>, Alex Bennée <alex.bennee@xxxxxxxxxx>, <qemu-devel@xxxxxxxxxx>
- From: Huang Rui <ray.huang@xxxxxxx>
- Date: Tue, 19 Dec 2023 15:53:15 +0800
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=daynix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NHthmq3LNlURxrALGteQJH0pznfSph2Flea36JzSsgY=; b=MLvBuO3yxMd70JoCsgTbVfSZBMJhGSXFNuanCaxBiUQxEnCNwfxJADmLqievZxMUMU0bcaYLM2TScroFogx4rr4eabiGs0oTuga9+jtG0r3or5RP2nwb2ZKgA/MzUBNkT5aTI4bk7ejBNEH8nRmPh7EyuygCilfSaL+hfTxMsvyS6ln450n6WM57tunUqTzpn34j8iCAnW5ZbR0xPpuzGhZeEja8UOPu0raIPk609XW3SFMcgrWH99M/YuEvfo56Vcm6959rkqSjCXz2mim6mg+JsZbDk5YwlkhXE07psLjfGEWCwtrNWjukyhaYhdzpPIveHRvg89pP6kP6dv4iaw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NMG88yncB1UafCmWWVyd8M+0DNS/il0n75vxYFCuq31dim6bjZFIt6Ws3zFSRLNPstEFC3I20/3PH3cr5pZllsVw1BG04pSLJfjjTjQUI6YaS6hteDAeJbtauWE6Ijbi4p+6ensjcpf62GQiC34S4Bt1+hObaaTZ+YjC4YBkSOIwY0ee5SOGm0XDxcLLKAe9qHx1V8XaR2tvx+Q0bvFzSfID5yrHh78DulYNX9AKeDk78+WHPZFCNfRTEH7Uq+Imkfy8Ev3Wi+nyWQtaDWgw2R60xfKf63yLwAKuW2R75yUyhLOz8EHpvswZgVQu3nMK4AxtkrRgx4F2DEBmK2Ja4Q==
- Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Gurchetan Singh <gurchetansingh@xxxxxxxxxxxx>, <ernunes@xxxxxxxxxx>, Alyssa Ross <hi@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Alex Deucher <alexander.deucher@xxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxx>, Christian König <christian.koenig@xxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@xxxxxxx>, "Honglei Huang" <honglei1.huang@xxxxxxx>, Julia Zhang <julia.zhang@xxxxxxx>, "Chen Jiqian" <Jiqian.Chen@xxxxxxx>, Huang Rui <ray.huang@xxxxxxx>
- Delivery-date: Tue, 19 Dec 2023 07:55:00 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
From: Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>
When the memory region has a different life-cycle from that of her parent,
could be automatically released, once has been unparent and once all of her
references have gone away, via the object's free callback.
However, currently, the address space subsystem keeps references to the
memory region without first incrementing its object's reference count.
As a result, the automatic deallocation of the object, not taking into
account those references, results in use-after-free memory corruption.
More specifically, reference to the memory region is kept in flatview
ranges. If the reference count of the memory region is not incremented,
flatview_destroy(), that is asynchronous, may be called after memory
region's destruction. If the reference count of the memory region is
incremented, memory region's destruction will take place after
flatview_destroy() has released its references.
This patch increases the reference count of an owned memory region object
on each memory_region_ref() and decreases it on each memory_region_unref().
Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>
Signed-off-by: Huang Rui <ray.huang@xxxxxxx>
---
Changes in v6:
- remove in-code comment because it is confusing and explain the issue,
that the patch attempts to fix, with more details in commit message
system/memory.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/system/memory.c b/system/memory.c
index 304fa843ea..4d5e7e7a4c 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -1824,6 +1824,7 @@ void memory_region_ref(MemoryRegion *mr)
* we do not ref/unref them because it slows down DMA sensibly.
*/
if (mr && mr->owner) {
+ object_ref(OBJECT(mr));
object_ref(mr->owner);
}
}
@@ -1832,6 +1833,7 @@ void memory_region_unref(MemoryRegion *mr)
{
if (mr && mr->owner) {
object_unref(mr->owner);
+ object_unref(OBJECT(mr));
}
}
--
2.25.1
|