[RFC] utterly bogus userland API in infinibad

From: Al Viro (viro_at_ftp.linux.org.uk)
Date: 09/16/05

  • Next message: Al Viro: "Re: [PATCH 2.6.13.1] Patch for invisible threads"
    Date:	Fri, 16 Sep 2005 19:11:32 +0100
    To: Linus Torvalds <torvalds@osdl.org>
    
    

    Exhibit A:

            opening uverbs... is done by ib_uverbs_open() (in
    drivers/infinib*d/core/uverbs_main.c). Aside of a number of obvious
    leaks, it does a number of calls of ib_uverbs_event_init(). Each of
    those does something amazingly bogus:
            * allocates a descriptor
            * allocates struct file
            * associates that struct file with root of their pseudo-fs
            * inserts it into caller's descriptor table
    ... and leaves an unknown number of those if open() fails, while we
    are at it. With zero indications for caller and no way to find out.

            What's more, you _can_ get those descriptors afterwards, if open()
    had succeeded. All you need to do is...

    Exibit B:
            ... write() to said descriptor. Buffer should contain a struct
    that will be interpreted. Results will be written to user memory, at the
    addresses contained in that struct. Said results might include the
    descriptors shat upon by open(). Nice way to hide an ioctl(), folks...

    Note that this "interface" assumes that only original opener will write
    to that file - for anybody else descriptors obviously will not make any
    sense.

    BTW, due to the way we do opens, if another thread sharing descriptor
    table will guess the number of first additional descriptor to be opened
    and just loops doing close() on it, we'll actually get our ib_uverbs_file
    kfreed right under us.

    May I ask who had come up with that insanity? Aside of inherent ugliness
    and abuse of fs syscalls, it simply doesn't work. E.g. leaks on failed
    open() are going to be fun to fix...
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Al Viro: "Re: [PATCH 2.6.13.1] Patch for invisible threads"

    Relevant Pages

    • For the almost 4-year anniversary: O_CLOEXEC again
      ... opens the directory using open. ... decides whether newly allocated descriptors are CLOEXEC until further ... I sincerely hope that this is not again answered with curses on POSIX ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • process file descriptor limit handling
      ... The current kernel have a problem ... The programs opens descriptors up to ... The open call should fail. ...
      (Linux-Kernel)
    • Re: Whats with these UD nipple bottles?
      ... Good fluid flow, opens ... and closes very easily, never leaks, easy to clean. ...
      (rec.running)
    • Re: password (& host?) file lookups, daemons and stray descriptors
      ... > * calls getpwuid() as part of a security check during ... > * opens a lockfile and does a lockf on it. ... I think the solution is obvious: don't close all file descriptors, ... if your daemon execs other programs. ...
      (comp.sys.hp.hpux)
    • Re: password (& host?) file lookups, daemons and stray descriptors
      ... > * calls getpwuid() as part of a security check during ... > * opens a lockfile and does a lockf on it. ... I think the solution is obvious: don't close all file descriptors, ... if your daemon execs other programs. ...
      (comp.unix.programmer)