Re: Sound driver security hole?

Itai Nahshon (nahshon@actcom.co.il)
Sat, 31 Jan 1998 02:00:15 +0200

Linus Torvalds wrote:
>
> The sound driver still knows that it is in use because the kernel has not
> done an "inode->i_op->put_inode" on the inode in question. If the sound
> module has decremented the module count to zero even though there are
> inodes in use, then it's a sound module bug (and not strictly related to
> mmap at all, although I think mmap() is the only way to keep a reference
> to the inode/dentry while dropping the file reference).
>
> Linus

After reading the code I still stand by my previous reply on the same
subject.

The call to the device relese is from __fput, after the use count on the
file is dropped to 0, even if there is still a use count on the dentry
(sound_mmap calls dget) and on the inode.

The device will not have a chance to close itself later, when calling
munmap
or when the exits.

IMHO the only clean solution to the problem is in moving the call to
release
the device/file to dput, or to iput (when dentry or inode use count drop
to 0). It looks like a big change but chances are that it will clean up
some other places as well.

I made a quick look for other places which may suffer from the dsame
problem.
I found only drivers/char/fbmem.c which has both a mmep and release
functions.
But... fbmem is NEVER referenced or used !!!

Itai

-- 
Itai Nahshon   nahshon@actcom.co.il
        Also   nahshon@vnet.ibm.com