2011-02-12 03:30:00

by Kees Cook

[permalink] [raw]
Subject: [PATCH] drm: do not leak kernel addresses via /proc/dri/*/vma

In the continuing effort to avoid kernel addresses leaking to unprivileged
users, this patch switches to %pK for /proc/dri/*/vma.

Signed-off-by: Kees Cook <[email protected]>
---
drivers/gpu/drm/drm_info.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index 3cdbaf3..be9a9c0 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -283,17 +283,18 @@ int drm_vma_info(struct seq_file *m, void *data)
#endif

mutex_lock(&dev->struct_mutex);
- seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n",
+ seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
atomic_read(&dev->vma_count),
- high_memory, (u64)virt_to_phys(high_memory));
+ high_memory, (void *)virt_to_phys(high_memory));

list_for_each_entry(pt, &dev->vmalist, head) {
vma = pt->vma;
if (!vma)
continue;
seq_printf(m,
- "\n%5d 0x%08lx-0x%08lx %c%c%c%c%c%c 0x%08lx000",
- pt->pid, vma->vm_start, vma->vm_end,
+ "\n%5d 0x%pK-0x%pK %c%c%c%c%c%c 0x%08lx000",
+ pt->pid,
+ (void *)vma->vm_start, (void *)vma->vm_end,
vma->vm_flags & VM_READ ? 'r' : '-',
vma->vm_flags & VM_WRITE ? 'w' : '-',
vma->vm_flags & VM_EXEC ? 'x' : '-',
--
1.7.2.3

--
Kees Cook
Ubuntu Security Team


2011-02-12 18:13:15

by Corbin Simpson

[permalink] [raw]
Subject: Re: [PATCH] drm: do not leak kernel addresses via /proc/dri/*/vma

On Fri, Feb 11, 2011 at 7:29 PM, Kees Cook <[email protected]> wrote:
> In the continuing effort to avoid kernel addresses leaking to unprivileged
> users, this patch switches to %pK for /proc/dri/*/vma.
>
> Signed-off-by: Kees Cook <[email protected]>
> ---
> ?drivers/gpu/drm/drm_info.c | ? ?9 +++++----
> ?1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
> index 3cdbaf3..be9a9c0 100644
> --- a/drivers/gpu/drm/drm_info.c
> +++ b/drivers/gpu/drm/drm_info.c
> @@ -283,17 +283,18 @@ int drm_vma_info(struct seq_file *m, void *data)
> ?#endif
>
> ? ? ? ?mutex_lock(&dev->struct_mutex);
> - ? ? ? seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n",
> + ? ? ? seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
> ? ? ? ? ? ? ? ? ? atomic_read(&dev->vma_count),
> - ? ? ? ? ? ? ? ? ?high_memory, (u64)virt_to_phys(high_memory));
> + ? ? ? ? ? ? ? ? ?high_memory, (void *)virt_to_phys(high_memory));
>
> ? ? ? ?list_for_each_entry(pt, &dev->vmalist, head) {
> ? ? ? ? ? ? ? ?vma = pt->vma;
> ? ? ? ? ? ? ? ?if (!vma)
> ? ? ? ? ? ? ? ? ? ? ? ?continue;
> ? ? ? ? ? ? ? ?seq_printf(m,
> - ? ? ? ? ? ? ? ? ? ? ? ? ?"\n%5d 0x%08lx-0x%08lx %c%c%c%c%c%c 0x%08lx000",
> - ? ? ? ? ? ? ? ? ? ? ? ? ?pt->pid, vma->vm_start, vma->vm_end,
> + ? ? ? ? ? ? ? ? ? ? ? ? ?"\n%5d 0x%pK-0x%pK %c%c%c%c%c%c 0x%08lx000",
> + ? ? ? ? ? ? ? ? ? ? ? ? ?pt->pid,
> + ? ? ? ? ? ? ? ? ? ? ? ? ?(void *)vma->vm_start, (void *)vma->vm_end,
> ? ? ? ? ? ? ? ? ? ? ? ? ? vma->vm_flags & VM_READ ? 'r' : '-',
> ? ? ? ? ? ? ? ? ? ? ? ? ? vma->vm_flags & VM_WRITE ? 'w' : '-',
> ? ? ? ? ? ? ? ? ? ? ? ? ? vma->vm_flags & VM_EXEC ? 'x' : '-',
> --
> 1.7.2.3

This is a highly reasonable patch. Does 0x%pK show up as 0x0x0 in the
log, or just 0x0? Other than that...

Reviewed-by: Corbin Simpson <[email protected]>

--
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<[email protected]>

2011-02-12 22:08:38

by Kees Cook

[permalink] [raw]
Subject: Re: [PATCH] drm: do not leak kernel addresses via /proc/dri/*/vma

Hi Corbin,

On Sat, Feb 12, 2011 at 10:13:04AM -0800, Corbin Simpson wrote:
> On Fri, Feb 11, 2011 at 7:29 PM, Kees Cook <[email protected]> wrote:
> > In the continuing effort to avoid kernel addresses leaking to unprivileged
> > users, this patch switches to %pK for /proc/dri/*/vma.
>
> This is a highly reasonable patch. Does 0x%pK show up as 0x0x0 in the
> log, or just 0x0? Other than that...
> Reviewed-by: Corbin Simpson <[email protected]>

Thanks! The default for %p (and %pK) is without the 0x prefix, and 0-padded to sizeof(void*)
character. So 0x%pK will show as 0x00000000 on 32bit to a regular user, etc.

-Kees

--
Kees Cook
Ubuntu Security Team