Messages in this thread Patch in this message | | | Subject | Re: [RFC 12/12][PATCH] SCHED_DEADLINE: modified sched_*_ex API | From | Peter Zijlstra <> | Date | Mon, 28 Dec 2009 16:09:18 +0100 |
| |
On Fri, 2009-10-16 at 17:48 +0200, Raistlin wrote: > @@ -6807,9 +6811,10 @@ out_unlock: > /** > * sys_sched_getparam - get the DEADLINE task parameters of a thread > * @pid: the pid in question. > + * @len: size of data pointed by param_ex. > * @param_ex: structure containing the new parameters (deadline, runtime, etc.). > */ > -SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid, > +SYSCALL_DEFINE3(sched_getparam_ex, pid_t, pid, unsigned, len, > struct sched_param_ex __user *, param_ex) > { > struct sched_param_ex lp; > @@ -6818,6 +6823,8 @@ SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid, > > if (!param_ex || pid < 0) > return -EINVAL; > + if (len < sizeof(struct sched_param_ex)) > + return -EINVAL; > > read_lock(&tasklist_lock); > p = find_process_by_pid(pid);
This allows len > sizeof().
> @@ -6837,7 +6844,7 @@ SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid, > /* > * This one might sleep, we cannot do it with a spinlock held ... > */ > - retval = copy_to_user(param_ex, &lp, sizeof(*param_ex)) ? -EFAULT : 0; > + retval = copy_to_user(param_ex, &lp, len) ? -EFAULT : 0; > > return retval;
Which would copy more than lp, resulting in a stack leak, right?
| |