diff options
author | Miklos Szeredi <mszeredi@suse.cz> | 2008-05-01 04:34:45 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-05-01 08:03:59 -0700 |
commit | 02c6be615f1fcd37ac5ed93a3ad6692ad8991cd9 (patch) | |
tree | 9c5047ed8b165a3388d5c61b2702f7cc12954766 /MAINTAINERS | |
parent | 2850699c59d513a0cd0c68f60f75609a5f9d4d32 (diff) | |
download | kernel_samsung_smdk4412-02c6be615f1fcd37ac5ed93a3ad6692ad8991cd9.zip kernel_samsung_smdk4412-02c6be615f1fcd37ac5ed93a3ad6692ad8991cd9.tar.gz kernel_samsung_smdk4412-02c6be615f1fcd37ac5ed93a3ad6692ad8991cd9.tar.bz2 |
vfs: fix permission checking in sys_utimensat
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.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions