lkml.org 
[lkml]   [2010]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [autofs] [PATCH][RFC] autofs4: Do not potentially dereference null pointer returned by fget() in autofs_dev_ioctl_setpipefd()
From
Date
On Mon, 2010-12-13 at 00:02 +0100, Jesper Juhl wrote:
> Hi,
>
> In fs/autofs4/dev-ioctl.c::autofs_dev_ioctl_setpipefd() we call fget(),
> which may return NULL, but we do not explicitly test for that NULL return
> so we may end up dereferencing a NULL pointer - bad.

Oops, thanks for this.

>
> A comment in fget() says "File object ref couldn't be taken" when that
> function returns NULL, so I guess EBUSY is the proper error to return from
> autofs_dev_ioctl_setpipefd() when this happens, but I'm far from sure
> about this, so I'd like some feedback before this patch is merged.

Not sure EBUSY is the one to use.

What is happening here is that user space has opened a file handle it
thinks is against an autofs mount point (which may actually be covered
by another mount, hence the need for an ioctl) and is asking the kernel
to set it in the super block info struct so it can be used for control
operations. By the look of fget() a NULL return would happen if the file
table was full (ENFILE) or the file handle had already been closed
(probably EBADF) so perhaps EBADF would be a better choice.

>
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> dev-ioctl.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> compile tested only.
>
> diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
> index eff9a41..ab551ee 100644
> --- a/fs/autofs4/dev-ioctl.c
> +++ b/fs/autofs4/dev-ioctl.c
> @@ -372,6 +372,10 @@ static int autofs_dev_ioctl_setpipefd(struct file *fp,
> return -EBUSY;
> } else {
> struct file *pipe = fget(pipefd);
> + if (!pipe) {
> + err = -EBUSY;
> + goto out;
> + }
> if (!pipe->f_op || !pipe->f_op->write) {
> err = -EPIPE;
> fput(pipe);
>
>
>




\
 
 \ /
  Last update: 2010-12-15 04:05    [W:0.072 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site