[lkml]   [2010]   [Dec]   [17]   [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()
On Wed, 15 Dec 2010, Ian Kent wrote:

> 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.
Ok. That makes sense.
I'll re-spin the patch with that change and re-submit it soon.

Jesper Juhl <>
Don't top-post
Plain text mails only, please.

 \ /
  Last update: 2010-12-17 13:15    [W:0.209 / U:0.044 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site