Re: 2.6.22-rc6(mm1) Unable to handle kernel NULL pointer dereference - git-bisect result

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 8 Jul 2007, Linus Torvalds wrote:
> 
> No.
> 
> notify_change() does *not* do permission checks for 
> ATTR_CTIME/MTIME/ATIME.
> 
> It does them for the "xxx_SET" attributes, but MTIME/ATIME is expected to 
> change when other things change, so notify_change() expects that those 
> _other_ changes have been validated from a security standpoint!
> 
> utimes() is special.

This might be an acceptable patch.

Al? What do you think? Basically, it says that

 - the file owner can always set MTIME/ATIME, of course

 - non-owners can set it only when they have write permissions, and if it 
   was a file descriptor, the only way for us to know that they have write 
   permissions is if it's opened writably, which is hopefully equivalent 
   to that MAY_WRITE test (except the MAY_WRITE test was done at _open_ 
   time).

This would seem to be the minimal change, and I think it's right.

		Linus

---
 fs/utimes.c |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/utimes.c b/fs/utimes.c
index 480f7c8..b3c8895 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -106,9 +106,16 @@ long do_utimes(int dfd, char __user *filename, struct timespec *times, int flags
                 if (IS_IMMUTABLE(inode))
                         goto dput_and_out;
 
-		if (current->fsuid != inode->i_uid &&
-		    (error = vfs_permission(&nd, MAY_WRITE)) != 0)
-			goto dput_and_out;
+		if (current->fsuid != inode->i_uid) {
+			if (f) {
+				if (!(f->f_mode & FMODE_WRITE))
+					goto dput_and_out;
+			} else {
+				error = vfs_permission(&nd, MAY_WRITE);
+				if (error)
+					goto dput_and_out;
+			}
+		}
 	}
 	mutex_lock(&inode->i_mutex);
 	error = notify_change(dentry, &newattrs);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/