linux-kernel - RE: [PATCH 1/1] drm/hyperv: Fix address space leak when Hyper-V DRM device is removed

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]

Message-ID:
 <SN6PR02MB4157BE3E0D84856CF6F22361D4FD2@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Tue, 11 Feb 2025 15:36:50 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Thomas Zimmermann <tzimmermann@...e.de>, "drawat.floss@...il.com"
	<drawat.floss@...il.com>, "maarten.lankhorst@...ux.intel.com"
	<maarten.lankhorst@...ux.intel.com>, "mripard@...nel.org"
	<mripard@...nel.org>, "airlied@...il.com" <airlied@...il.com>,
	"simona@...ll.ch" <simona@...ll.ch>, "christophe.jaillet@...adoo.fr"
	<christophe.jaillet@...adoo.fr>, "ssengar@...ux.microsoft.com"
	<ssengar@...ux.microsoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>
CC: "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>
Subject: RE: [PATCH 1/1] drm/hyperv: Fix address space leak when Hyper-V DRM
 device is removed

From: Thomas Zimmermann <tzimmermann@...e.de> Sent: Monday, February 10, 2025 11:35 PM
> 
> Hi
> 
> Am 10.02.25 um 20:34 schrieb mhkelley58@...il.com:
> > From: Michael Kelley <mhklinux@...look.com>
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram, and maps it cacheable. If the device removed, or in the error
> > path for device probing, the MMIO space is released but no unmap is done.
> > Consequently the kernel address space for the mapping is leaked.
> >
> > Fix this by adding iounmap() calls in the device removal path, and in the
> > error path during device probing.
> 
> Could this driver use devm_ helpers for iomap operations? That should
> fix the issue automatically.

Possibly. But there's no devm_ioremap_cache(). There are _uc and _wc
flavors, but not _wb. I'd guess that full writeback caching was deemed
nonsensical for a device. But it does make sense in this case of framebuffer
memory shared with a hypervisor that is also using WB caching. Adding
a _wb devm_ helper might be seen as something of an abomination. :-)

Michael

> 
> Best regards
> Thomas
> 
> >
> > Fixes: f1f63cbb705d ("drm/hyperv: Fix an error handling path in
> hyperv_vmbus_probe()")
> > Fixes: a0ab5abced55 ("drm/hyperv : Removing the restruction of VRAM allocation
> with PCI bar size")
> > Signed-off-by: Michael Kelley <mhklinux@...look.com>
> > ---
> >   drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> > index e0953777a206..b491827941f1 100644
> > --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> > +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> > @@ -156,6 +156,7 @@ static int hyperv_vmbus_probe(struct hv_device *hdev,
> >   	return 0;
> >
> >   err_free_mmio:
> > +	iounmap(hv->vram);
> >   	vmbus_free_mmio(hv->mem->start, hv->fb_size);
> >   err_vmbus_close:
> >   	vmbus_close(hdev->channel);
> > @@ -174,6 +175,7 @@ static void hyperv_vmbus_remove(struct hv_device *hdev)
> >   	vmbus_close(hdev->channel);
> >   	hv_set_drvdata(hdev, NULL);
> >
> > +	iounmap(hv->vram);
> >   	vmbus_free_mmio(hv->mem->start, hv->fb_size);
> >   }
> >
> 
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)