Description of problem:

If utimensat() is called with both times set to UTIME_NOW or one of them to
UTIME_NOW and the other to UTIME_OMIT, then it will update the file time
without any permission checking.

I don't think this can be used for anything other than a local DoS, but could
be quite bewildering at that (e.g.  "Why was that large source tree rebuilt
when I didn't modify anything???")

This affects all kernels from 2.6.22, when the utimensat() syscall was
introduced.

Fix by doing the same permission checking as for the "times == NULL" case.

Thanks to Michael Kerrisk, whose utimensat-non-conformances-and-fixes.patch in
-mm also fixes this (and breaks other stuff), only he didn't realize the
security implications of this bug.

Version-Release number of selected component (if applicable):
2.6.22->2.6.25.2

Additional info:

This issue doesn't affect RHEL kernels as the utimensat() system call
is not yet present in 2.6.18 version of the Linux kernel (filling only
against Fedora kernels).

Proposed upstream patch:

http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob;f=review-2.6.25/vfs-fix-permission-checking-in-sys_utimensat.patch;h=1da0b9bf9f078e3eb147a6799e5a74af2484014a;hb=cbe22288b271b4e4e51f5573281662f53466e41a