Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 02 Jun 2009 11:54:04 +0200
From: Miklos Szeredi <>
To: Jon Oberheide <>
Subject: Re: CVE request: kernel: splice local denial of

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.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.