[Bug 12987] internal kernel memory corruption caused by inotify not validating input from userspace
bugzilla-daemon at bugzilla.ubuntu.com
bugzilla-daemon at bugzilla.ubuntu.com
Wed Jul 27 07:48:47 UTC 2005
Please do not reply to this email. You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=12987
Ubuntu | linux
desrt at desrt.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|lots of kernel oopses caused|internal kernel memory
|by using inotify syscalls |corruption caused by inotify
| |not validating input from
| |userspace
------- Additional Comments From desrt at desrt.ca 2005-07-27 08:48 UTC -------
OK. More info:
This bug occured because Ubuntu's syscall numbers are out of sync with those of
the official kernel. That's not really the bug, though. But basically:
I did
# define __NR_inotify_init 291
which in Ubuntu's kernel is actually inotify_rm_watch.
Just because of the way it worked out, the first argument to the call ends up
being 0.
So I end up effectively calling inotify_rm_watch( 0, [junk] );
The inotify code in the kernel (including upstream) does a lookup on the FD but
doesn't check what *type* of fd it is (in the case of '0' it refers to stdin)
Inotify then treats the private_data member of the file descriptor in question
as an inotify datatype (even if it's not!) This results in corruption in the
kernel and leads to the PTY oopses.
>From upstream (vanilla) kernel source:
asmlinkage long sys_inotify_rm_watch(int fd, u32 wd)
{
struct file *filp;
struct inotify_device *dev;
int ret;
filp = fget(fd);
if (!filp)
return -EBADF;
/* no check to see what type of fd we're dealing with */
dev = filp->private_data; /* we don't know what type this
private_data is! */
ret = inotify_ignore (dev, wd);
fput(filp);
return ret;
}
Will email Robert about this.
--
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
More information about the kernel-bugs
mailing list