Re: CVE request: kernel: issue with O_EXCL creates on NFSv4

[Eugene Teo <eugene () redhat com>]

Steven M. Christey wrote:
> On Mon, 21 Sep 2009, Eugene Teo wrote:
> > Upstream commits:
> > http://git.kernel.org/linus/af85852d (fixed in v2.6.19-rc6)
> > http://git.kernel.org/linus/81ac95c5 (fixed in v2.6.19-rc6)
> > http://git.kernel.org/linus/79fb54ab (fixed in v2.6.30-rc1)
>
> I can't see any clear relationship between these commits and the Red Hat
> bugzilla entry.  The implication that there were two fixes, one in 2.6.19
> and one in 2.6.30, is also confusing because if a fix in 2.6.19 didn't
> work, we'd normally assign a new CVE for the fix in 2.6.30.
>
> CVE-2009-3286 is below, anchored on what's said in Bugzilla 524520. Since
> 81ac95c also mentions do_open_permission, I used that as a reference.
> This suggests the problem was fixed in 2006, but this issue doesn't have a
> CVE identifier because security implications weren't spelled out until
> Eugene's post (as far as I can tell.)

Hi Steve,

Sorry for the confusion.

The upstream commit should just be http://git.kernel.org/linus/79fb54ab.

On an O_EXCL create, the kernel was passing a bogus mode to the 
vfs_create() op, which caused the file to be created with non-sensical 
(and possibly unsafe) permissions. The intention was to pass a mode with 
all of the permission bits cleared, but the field wasn't necessarily 
zeroed out.

When the create is successful, this isn't very noticable. The client 
will follow up the create with a SETATTR call and fix the mode and 
permissions. Still, there was a window of opportunity where the file 
might have "unsafe" perms even when the CREATE op returns success.

This was a long standing problem fixed in 2.6.30 or so, seemingly 
inadvertently as part of the merge of the NFSv4.1 code.

The other two commits were for another bug that we fixed.

Thanks, Eugene