Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Oct 2008 06:40:02 GMT
From:      Nate Eldredge <neldredge@math.ucsd.edu>
To:        freebsd-fs@FreeBSD.org
Subject:   Re: kern/127213: [tmpfs] sendfile on tmpfs data corruption
Message-ID:  <200810060640.m966e2qg084501@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/127213; it has been noted by GNATS.

From: Nate Eldredge <neldredge@math.ucsd.edu>
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810060640.m966e2qg084501>