All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Gregory Haskins <ghaskins@novell.com>,
	kvm@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	avi@redhat.com, hirofuchi@users.sourceforge.net,
	ericvh@gmail.com
Subject: file descriptor abuses
Date: Sun, 3 May 2009 20:22:01 +0100	[thread overview]
Message-ID: <20090503192201.GA8633@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20090503190136.GY8633@ZenIV.linux.org.uk>

On Sun, May 03, 2009 at 08:01:36PM +0100, Al Viro wrote:

> General rules:
> 	* descriptor you've generated is fit only for return to userland;
> 	* descriptor you've got from userland is fit only for *single*
> fget() or equivalent, unless you are one of the core syscalls manipulating
> the descriptor table itself (dup2, etc.)
> 	* once file is installed in descriptor table, you'd better be past
> the last failure exit; sys_close() on cleanup path is not acceptable.
> That's what reserving descriptors is for.
> 
> IOW, the sane solution would be to export something that returns your
> struct file *.  And stop playing with fd completely.

Speaking of which, quick look through fget() callers shows this turd:

static int p9_socket_open(struct p9_client *client, struct socket *csocket)
{
	int fd, ret;

	fd = sock_map_fd(csocket, 0);
	.....

	ret = p9_fd_open(client, fd, fd);
	if (ret < 0) {
		P9_EPRINTK(KERN_ERR, "p9_socket_open: failed to open fd\n");
		sockfd_put(csocket);
		return ret;
	}
	.....
	return 0;
}

where p9_fd_open() calls fget() on its 2nd and 3rd arguments.  Which does
worse than just a leak, AFAICT - on failure exit it leaves a dangling
pointer from descriptor table.

On the almost unrelated note, we have (in drivers/sneak_in^Wstaging/usbip)
sockfd_to_socket(), with all callers leaking struct file, AFAICS.

  reply	other threads:[~2009-05-03 19:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-27 18:33 [KVM PATCH v3 0/2] irqfd Gregory Haskins
2009-04-27 18:33 ` [KVM PATCH v3 1/2] eventfd: export fget and signal interfaces for module use Gregory Haskins
2009-04-27 18:33 ` [KVM PATCH v3 2/2] kvm: add support for irqfd via eventfd-notification interface Gregory Haskins
2009-04-30 13:07   ` Michael S. Tsirkin
2009-05-03 16:59     ` Avi Kivity
2009-05-03 19:04       ` Michael S. Tsirkin
2009-05-03 19:17         ` Avi Kivity
2009-05-03 19:25           ` Michael S. Tsirkin
2009-05-03  6:44   ` Al Viro
2009-05-03 18:07     ` Davide Libenzi
2009-05-03 19:01       ` Al Viro
2009-05-03 19:22         ` Al Viro [this message]
2009-05-03 20:11         ` Davide Libenzi
2009-05-03 20:31           ` Al Viro
2009-04-29  6:10 ` [KVM PATCH v3 0/2] irqfd Andrew Morton
2009-04-29  8:18   ` Avi Kivity

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=20090503192201.GA8633@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=avi@redhat.com \
    --cc=davidel@xmailserver.org \
    --cc=ericvh@gmail.com \
    --cc=ghaskins@novell.com \
    --cc=hirofuchi@users.sourceforge.net \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.