[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.022 / U:2.068 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site