lkml.org 
[lkml]   [2008]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 20/24] perfmon: system calls interface

* eranian@googlemail.com <eranian@googlemail.com> wrote:

> +/*
> + * unlike the other perfmon system calls, this one returns a file descriptor
> + * or a value < 0 in case of error, very much like open() or socket()
> + */
> +asmlinkage long sys_pfm_create(int flags, struct pfarg_sinfo __user *ureq)
> +{
> + struct pfm_context *new_ctx;
> + struct pfarg_sinfo sif;
> + int ret;
> +
> + PFM_DBG("flags=0x%x sif=%p", flags, ureq);
> +
> + if (perfmon_disabled)
> + return -ENOSYS;
> +
> + if (flags) {
> + PFM_DBG("no flags accepted yet");
> + return -EINVAL;
> + }
> + ret = __pfm_create_context(flags, &sif, &new_ctx);
> +
> + /*
> + * copy sif to user level argument, if requested
> + */
> + if (ureq && copy_to_user(ureq, &sif, sizeof(sif))) {
> + pfm_undo_create(ret, new_ctx);
> + ret = -EFAULT;
> + }
> + return ret;
> +}

the error control flow of fd creation is sloppy here and has an
kernel-data information leak: if __pfm_create_context() fails:

- due to memory pressure
- or due to lack of CPU support
- or due to lack of permissions
- or due to a busy PMU

then &sif is not initialized, and sys_pfm_create() copies it to
user-space. This way attackers can probe portions of the kernel stack.

Worse than that, there's also a DoS hole here: in the same scenario
above (easily created by attackers), new_ctx is not initialized either
- and if a ureq is provided by (unprivileged) userspace with a
faulting address (say ureq == (void *)1), then sys_pfm_create() will
call pfm_undo_create() => kaboom.

It's even a root hole, because attacker can likely prime the kernel
stack with arbitrary values via prior syscalls and hence controls
new_ctx's value, and the freeing logic happily uses it => local root
hole.

Is this stuff in any distro kernel?

Ingo


\
 
 \ /
  Last update: 2008-11-26 14:49    [W:0.144 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site