Re: [patch 10/13] signal/timer/event fds v8 - eventfd core ...

[Davide Libenzi]

On Fri, 30 Mar 2007, Andrew Morton wrote:

> On Fri, 30 Mar 2007 18:11:55 -0700 (PDT) Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote:
> 
> > 
> > > > + */
> > > 
> > > So it is the caller's responsibility to ensure that *file refers to an
> > > eventfd file?
> > 
> > In which function? I lost you ...
> > 
> 
> eventfd_signal() assumes that the passed in file* refers to an eventfd
> file.  So if a caller passes in a file* for /etc/passwd, the kernel will go
> splat.
> 
> I guess that's caveat emptor, and any violations of that will show up
> quickly in testing.  My main concern would be that there might be some way
> for a naughty user to force the kernel to pass a non-eventfd file* into
> this function.  That depends upon as-yet-unwritten code - is there a risk
> of this happening, and how do we prevent it?

That's the kernel side of the API. The userspace->kernel fd validation is 
done in eventfd_fget(), that the kernel uses to get an eventfd file* from 
an eventfd file descriptor. The eventfd_fget() does the file operations 
check and returns proper error.
At that point, if the kernel feeds eventfd_signal() with crap, it gets 
crap back. Like calling internal kernel functions with bogus mm_struct or 
task_struct.



> > > > +	DECLARE_WAITQUEUE(wait, current);
> > > > +
> > > > +	if (count < sizeof(ucnt))
> > > > +		return -EINVAL;
> > > > +	if (get_user(ucnt, (const __u64 __user *) buf))
> > > > +		return -EFAULT;
> > > 
> > > Some architectures do not implement 64-bit get_user()
> > 
> > copy_from_user it is, then ...
> > 
> 
> spose so.  I think architectures _should_ implement 64-bit get_user() and
> put_user() nowadays.  So you could leave the code as-is and inform the arch
> maintainers, if you're feeling keen.
> 
> If all this code has its own Kconfig options then the architectures won't
> break until their maintainers come along to enable the new features, so
> they'll implement 64-bit get_user() at that time and things will all unfold
> in a nicely non-chaotic fashion.

Agreed. I'll leave the get_user(u64).



- Davide


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