* [PATCH 1/2] drm/radeon: forbid mapping of userptr bo through radeon device file
@ 2016-04-19 13:07 Jérôme Glisse
2016-04-19 13:07 ` [PATCH 2/2] drm/amdgpu: " Jérôme Glisse
2016-04-20 13:26 ` [PATCH 1/2] drm/radeon: " Christian König
0 siblings, 2 replies; 4+ messages in thread
From: Jérôme Glisse @ 2016-04-19 13:07 UTC (permalink / raw)
To: dri-devel; +Cc: Jérôme Glisse, stable
Allowing userptr bo which are basicly a list of page from some vma
(so either anonymous page or file backed page) would lead to serious
corruption of kernel structures and counters (because we overwrite
the page->mapping field when mapping buffer).
This will already block if the buffer was populated before anyone does
try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
vm fault handler.
So to be safe just add a check to verify_access() callback.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: <stable@vger.kernel.org>
---
drivers/gpu/drm/radeon/radeon_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
index 7dddfdc..90f7394 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -235,6 +235,8 @@ static int radeon_verify_access(struct ttm_buffer_object *bo, struct file *filp)
{
struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
+ if (radeon_ttm_tt_has_userptr(bo->ttm))
+ return -EPERM;
return drm_vma_node_verify_access(&rbo->gem_base.vma_node, filp);
}
--
2.1.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH 2/2] drm/amdgpu: forbid mapping of userptr bo through radeon device file
2016-04-19 13:07 [PATCH 1/2] drm/radeon: forbid mapping of userptr bo through radeon device file Jérôme Glisse
@ 2016-04-19 13:07 ` Jérôme Glisse
2016-04-20 13:26 ` [PATCH 1/2] drm/radeon: " Christian König
1 sibling, 0 replies; 4+ messages in thread
From: Jérôme Glisse @ 2016-04-19 13:07 UTC (permalink / raw)
To: dri-devel; +Cc: Jérôme Glisse, stable
Allowing userptr bo which are basicly a list of page from some vma
(so either anonymous page or file backed page) would lead to serious
corruption of kernel structures and counters (because we overwrite
the page->mapping field when mapping buffer).
This will already block if the buffer was populated before anyone does
try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
vm fault handler.
So to be safe just add a check to verify_access() callback.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: <stable@vger.kernel.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6f3369d..11af449 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -223,6 +223,8 @@ static int amdgpu_verify_access(struct ttm_buffer_object *bo, struct file *filp)
{
struct amdgpu_bo *rbo = container_of(bo, struct amdgpu_bo, tbo);
+ if (amdgpu_ttm_tt_get_usermm(bo->ttm))
+ return -EPERM;
return drm_vma_node_verify_access(&rbo->gem_base.vma_node, filp);
}
--
2.1.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH 1/2] drm/radeon: forbid mapping of userptr bo through radeon device file
2016-04-19 13:07 [PATCH 1/2] drm/radeon: forbid mapping of userptr bo through radeon device file Jérôme Glisse
2016-04-19 13:07 ` [PATCH 2/2] drm/amdgpu: " Jérôme Glisse
@ 2016-04-20 13:26 ` Christian König
2016-04-20 15:06 ` Alex Deucher
1 sibling, 1 reply; 4+ messages in thread
From: Christian König @ 2016-04-20 13:26 UTC (permalink / raw)
To: Jérôme Glisse, dri-devel; +Cc: stable
There are also checks in (amdgpu|radeon)_gem_mmap_ioctl() to prevent
this as well.
But it shouldn't hurt us to check that here as well. So both patches are
Reviewed-by: Christian König <christian.koenig@amd.com>
Regards,
Christian.
Am 19.04.2016 um 15:07 schrieb Jérôme Glisse:
> Allowing userptr bo which are basicly a list of page from some vma
> (so either anonymous page or file backed page) would lead to serious
> corruption of kernel structures and counters (because we overwrite
> the page->mapping field when mapping buffer).
>
> This will already block if the buffer was populated before anyone does
> try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
> ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
> vm fault handler.
>
> So to be safe just add a check to verify_access() callback.
>
> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
> Cc: <stable@vger.kernel.org>
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 7dddfdc..90f7394 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -235,6 +235,8 @@ static int radeon_verify_access(struct ttm_buffer_object *bo, struct file *filp)
> {
> struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
>
> + if (radeon_ttm_tt_has_userptr(bo->ttm))
> + return -EPERM;
> return drm_vma_node_verify_access(&rbo->gem_base.vma_node, filp);
> }
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/2] drm/radeon: forbid mapping of userptr bo through radeon device file
2016-04-20 13:26 ` [PATCH 1/2] drm/radeon: " Christian König
@ 2016-04-20 15:06 ` Alex Deucher
0 siblings, 0 replies; 4+ messages in thread
From: Alex Deucher @ 2016-04-20 15:06 UTC (permalink / raw)
To: Christian König
Cc: Jérôme Glisse, Maling list - DRI developers, for 3.8
On Wed, Apr 20, 2016 at 9:26 AM, Christian König
<deathsimple@vodafone.de> wrote:
> There are also checks in (amdgpu|radeon)_gem_mmap_ioctl() to prevent this as
> well.
>
> But it shouldn't hurt us to check that here as well. So both patches are
> Reviewed-by: Christian König <christian.koenig@amd.com>
Applied both. Thanks!
Alex
>
> Regards,
> Christian.
>
> Am 19.04.2016 um 15:07 schrieb Jérôme Glisse:
>>
>> Allowing userptr bo which are basicly a list of page from some vma
>> (so either anonymous page or file backed page) would lead to serious
>> corruption of kernel structures and counters (because we overwrite
>> the page->mapping field when mapping buffer).
>>
>> This will already block if the buffer was populated before anyone does
>> try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
>> ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
>> vm fault handler.
>>
>> So to be safe just add a check to verify_access() callback.
>>
>> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
>> Cc: <stable@vger.kernel.org>
>> ---
>> drivers/gpu/drm/radeon/radeon_ttm.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>> index 7dddfdc..90f7394 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>> @@ -235,6 +235,8 @@ static int radeon_verify_access(struct
>> ttm_buffer_object *bo, struct file *filp)
>> {
>> struct radeon_bo *rbo = container_of(bo, struct radeon_bo, tbo);
>> + if (radeon_ttm_tt_has_userptr(bo->ttm))
>> + return -EPERM;
>> return drm_vma_node_verify_access(&rbo->gem_base.vma_node, filp);
>> }
>>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-04-20 15:06 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-19 13:07 [PATCH 1/2] drm/radeon: forbid mapping of userptr bo through radeon device file Jérôme Glisse
2016-04-19 13:07 ` [PATCH 2/2] drm/amdgpu: " Jérôme Glisse
2016-04-20 13:26 ` [PATCH 1/2] drm/radeon: " Christian König
2016-04-20 15:06 ` Alex Deucher
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).