[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1243936444.6148.31.camel@tucsk>
Date: Tue, 02 Jun 2009 11:54:04 +0200
From: Miklos Szeredi <mszeredi@...e.cz>
To: Jon Oberheide <jon@...rheide.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE request: kernel: splice local denial of
service
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.
Thanks,
Miklos
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.
