Openwall Project   /home  Owl  JtR  Pro  crypt  pam_passwdqc  tcb  phpass  scanlogd  popa3d  msulogin  /  Linux  BIND  /  advisories  presentations  /  services  donations  /  wordlists  passwords  /  NEWS  community  lists  Wiki  CVSweb  mirrors  signatures
bringing security into open environments
 
Password Recovery Resources on the Net
[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
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


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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ