The following reply was made to PR kern/127213; it has been noted by GNATS.

From: Nate Eldredge
Subject: Re: kern/127213: [tmpfs] sendfile on tmpfs data corruption
Date: Sun, 5 Oct 2008 23:20:42 -0700 (PDT)


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

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


Nate Eldredge
_______________________________________________ mailing list
To unsubscribe, send any mail to ""