Messages in this thread | | | Date | Wed, 26 Nov 2008 14:43:02 +0100 | From | Ingo Molnar <> | Subject | Re: [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
| |