From owner-svn-src-user@FreeBSD.ORG Sun May 4 18:07:55 2014 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 457FA250; Sun, 4 May 2014 18:07:55 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 895501133; Sun, 4 May 2014 18:07:54 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so1765469wib.5 for ; Sun, 04 May 2014 11:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vskeYiaDuerT+RicIeMHY/oA/VDETBk12tvYUfBZWUM=; b=sJAjS62bp2TXFS2rsTS3YYLA0p5UStxUOb8bPmT6RQUhOFxB2nto1yAYmvOxelmh5L mxuLGTwag+gqcRZ5Q6iMwLGgyD03uk6o7gsHKX/GBxMWP24piHeKDAKRq0wb6m78FXkp aHwoXTz9eE0aEdFqxQHtwuTg7V01uuw77eRFfqQbEwYOgtKLRQwGl9R3jXcxMCRSpTKZ +pw1zTSnepLmG7j0Ai7+XgWKKifr0+CmJVz+fUgGj0/nWi6WWaGDhbAjf5ZkdcdtlOQh 2QPU2xeL59QUxDdY7GzeaNrggjdAQi8OSM1X0BAMn9xptET1IRTfeWO2/qFeENiUAnU4 Uxag== X-Received: by 10.180.89.211 with SMTP id bq19mr12347808wib.22.1399226872756; Sun, 04 May 2014 11:07:52 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id dn1sm12295126wid.6.2014.05.04.11.07.51 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 04 May 2014 11:07:52 -0700 (PDT) Date: Sun, 4 May 2014 20:07:49 +0200 From: Mateusz Guzik To: Dmitry Chagin Subject: Re: svn commit: r265327 - in user/dchagin/lemul/sys: amd64/linux amd64/linux32 compat/linux conf i386/linux modules/linux modules/linux64 Message-ID: <20140504180749.GA17835@dft-labs.eu> References: <201405041559.s44FxWdj053353@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201405041559.s44FxWdj053353@svn.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: src-committers@freebsd.org, svn-src-user@freebsd.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 18:07:55 -0000 On Sun, May 04, 2014 at 03:59:32PM +0000, Dmitry Chagin wrote: > Author: dchagin > Date: Sun May 4 15:59:32 2014 > New Revision: 265327 > URL: http://svnweb.freebsd.org/changeset/base/265327 > > Log: > Implement epoll family system calls. This is a tiny wrapper around kqueue > to implement epoll subset of functionality. The kqueue user data are > 32bit on i386 which is not enough for epoll user data, so we keep user > data in the proc emuldata. > > Initial patch developed by rdivacky in 2007, then extended by > Yuri Victorovich @ r255672 and finished by me. > I'm not happy with this. The code is full of fp <-> fd lookup races. Example: linux_epoll_ctl if (args->epfd == args->fd) return (EINVAL); [..] error = fget(td, args->epfd, &rights, &epfp); if (error != 0) return (error); /* Protect user data vector from incorrectly supplied fd. */ error = fget(td, args->fd, &rights, &fp); if (error != 0) goto leave1; fds could resolve to the same fp right from the start and even if that was note done an attacker could arrange that after the check. There is no validation you got epoll fd either. Further down: switch (args->op) { case LINUX_EPOLL_CTL_MOD: /* * We don't memorize which events were set for this FD * on this level, so just delete all we could have set: * EVFILT_READ and EVFILT_WRITE, ignoring any errors */ error = epoll_delete_all_events(td, epfp, args->fd); Again a lookup. Whether this particular problem could be used to do something nasty I don't know, but playing like this is asking for trouble. The only solution I see is to modify kqueue functions to accept fps. -- Mateusz Guzik