linux-kernel - Re: [PATCH] drm: do not leak kernel addresses via /proc/dri/*/vma

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTiniMPKD6EGpQ=TAbeS4tFVtZybcf-8kFuNbU7t_@mail.gmail.com>
Date:	Sat, 12 Feb 2011 10:13:04 -0800
From:	Corbin Simpson <mostawesomedude@...il.com>
To:	Kees Cook <kees.cook@...onical.com>
Cc:	linux-kernel@...r.kernel.org,
	Dan Rosenberg <drosenberg@...curity.com>,
	Eugene Teo <eugeneteo@...nel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] drm: do not leak kernel addresses via /proc/dri/*/vma

On Fri, Feb 11, 2011 at 7:29 PM, Kees Cook <kees.cook@...onical.com> 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 <kees.cook@...onical.com>
> ---
>  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 <MostAwesomeDude@...il.com>

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

Corbin Simpson
<MostAwesomeDude@...il.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/