From owner-freebsd-fs@FreeBSD.ORG Mon Oct 6 06:40:02 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAF53106568E for ; Mon, 6 Oct 2008 06:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C98BD8FC17 for ; Mon, 6 Oct 2008 06:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m966e2tM084502 for ; Mon, 6 Oct 2008 06:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m966e2qg084501; Mon, 6 Oct 2008 06:40:02 GMT (envelope-from gnats) Date: Mon, 6 Oct 2008 06:40:02 GMT Message-Id: <200810060640.m966e2qg084501@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Nate Eldredge Cc: Subject: Re: kern/127213: [tmpfs] sendfile on tmpfs data corruption X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Eldredge List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2008 06:40:02 -0000 The following reply was made to PR kern/127213; it has been noted by GNATS. From: Nate Eldredge To: bug-followup@FreeBSD.org, citrin@citrin.ru Cc: Subject: Re: kern/127213: [tmpfs] sendfile on tmpfs data corruption Date: Sun, 5 Oct 2008 23:20:42 -0700 (PDT) Hi, I investigated this a bit. First, note that this bug has some security implications, because it appears that the garbage written by sendfile is kernel memory contents, which could contain something sensitive. It is sufficient for an attacker to have read access to a file on a mounted tmpfs. So it should really get fixed. I'm not terribly familiar with vfs or vm internals, but it appears that sendfile causes VOP_READ to be called with the IO_VMIO flag and a dummy uio. tmpfs_read (in sys/fs/tmpfs/tmpfs_vnops.c) doesn't handle this correctly; it always just copies the data to the supplied uio, which in this case does nothing. It looks like the data is supposed to make it into vn->v_object, and tmpfs_read doesn't do that. (If I understand it correctly, on a normal filesystem this is taken care of by bread().) I am not sure what the correct semantics of IO_VMIO are supposed to be, so I don't know what the correct fix would be. However, a quick fix is to not have a v_object at all; remove the call to vnode_create_vobject in tmpfs_open. This seems to be legal since procfs, etc, work that way. It does however mean that sendfile doesn't work at all. I am curious what was the point of having a v_object in the first place, since the data is already in virtual memory. Unless the goal was just to make sendfile work, which evidently wasn't successful. Incidentally, to the initial reporter, what application do you have that requires sendfile? In my experience, most things will fall back to a read/write loop if sendfile fails, since sendfile isn't available on all systems or under all circumstances. So if you apply the quick fix so that sendfile always fails, it might at least get your application working again. -- Nate Eldredge neldredge@math.ucsd.edu