[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A25D1BD.6030302@redhat.com>
Date: Wed, 03 Jun 2009 09:28:29 +0800
From: Eugene Teo <eugene@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: kernel: splice local denial of service
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
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.
