Re: CVE request: kernel: splice local denial of service

[Eugene Teo <eugene () redhat com>]

Miklos Szeredi wrote:
> On Sat, 2009-05-30 at 03:36 -0400, Jon Oberheide wrote:
> > The deadlock can be reproduced easily (you might need to fork() a few
> > times to get an pipe inode allocation ptr less than the file inode ptr):
> >
> >     pipe(pfds);
> >     snprintf(buf, sizeof(buf), "/tmp/%d", getpid());
> >     fd = open(buf, O_RDWR | O_CREAT, S_IRWXU);
> >
> >     if (fork()) {
> >         splice(pfds[0], NULL, fd, NULL, 1024, NULL);
> >     } else{
> >         sleep(1);
> >         splice(pfds[0], NULL, fd, NULL, 1024, NULL);
> >     }
> >
> > However, the deadlock only affects the task attempting to acquire the
> > inode's i_mutex, so an attacker would require write access to a file
> > that is also written (or other fs op that acquires i_mutex) by some
> > victim process.  That is, unless I've missed something. :-)
>
> Some operations also take i_mutex on parent (open(O_CREAT), mkdir,
> unlink, rmdir, rename, etc), and the order is always parent first.  This
> means, that if some task is holding i_mutex on /tmp/foo, then doing
> unlink("/tmp/foo") will block while holding i_mutex on /tmp.  Together
> with the above deadlock it will prevent creation or removal of files
> under /tmp, making the system pretty much unusable.

But it does not make the box unresponsive. In this example, you can
still ssh into the system as long as it does not create files in /tmp. I
gave it A:P for the availability impact of the CVSSv2 vector.

Thanks, Eugene