From: Al Viro <viro@ftp.linux.org.uk>
To: Linus Torvalds <torvalds@osdl.org>
Cc: linux-kernel@vger.kernel.org, rolandd@cisco.com
Subject: [RFC] utterly bogus userland API in infinibad
Date: Fri, 16 Sep 2005 19:11:32 +0100 [thread overview]
Message-ID: <20050916181132.GF19626@ftp.linux.org.uk> (raw)
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...
next reply other threads:[~2005-09-16 18:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-16 18:11 Al Viro [this message]
2005-09-16 19:31 ` [RFC] utterly bogus userland API in infinibad Roland Dreier
2005-09-16 20:37 ` Al Viro
2005-09-16 23:54 ` Roland Dreier
2005-09-17 0:03 ` David S. Miller
2005-09-17 0:08 ` Roland Dreier
2005-09-19 22:25 ` Roland Dreier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050916181132.GF19626@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rolandd@cisco.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox