Messages in this thread | | | Date | Fri, 30 Jan 1998 13:44:37 +0100 | From | Thomas Sailer <> | Subject | Sound driver security hole? |
| |
Consider mmap'ing an ordinary file:
fd = open("some file" ...); mmap(..., MAP_SHARED, fd, ...); close(fd);
after the close, the file mapping is still there and you can still access the file via the mapping. This does certainly make sense.
Now let's look at sound. Consider a system where sound.o is demand loaded by kerneld. A malicious app does something like the following:
fd = open("/dev/dsp"...); some ioctls to set various parameters mmap(..., MAP_SHARED, fd, ...); close(fd);
At this point, the app has mapped the DMA buffer into its address space. The physical storage behind the mapping was allocated by the sound driver with get_free_pages, and it keeps this allocation around. But since the fd is closed again, the use count of the sound module is 0 and nothing prevents the module from being removed. Now the malicious app only has to wait until sound is removed by kerneld. When sound.o gets removed, it deallocates the dma buffer, giving the pages back to the kernel. _BUT_ the malicious process still has a mapping to them! And nothing I can think of prevents the kernel from reusing these pages.
Note that this is nothing Alan or myself introduced during our recent sound driver work, this is present also in the sound driver in 2.0.32.
Unless I haven't made a mistake in my reasoning, this is a rather serious problem that needs to be fixed.
One possibility would be to disable that feature altogether. I'm more and more convinced that the mmap feature is a pandora's box for no real benefit (that couldn't be done much simpler otherwise). But unfortunately some binary only "killer" applications deemed important like doom and quake use it. Therefore this might not be practical.
"The right thing to do" IMHO would be to remove the mapping at close() time. It doesn't make sense to keep the mapping around longer, as to use it reasonnably, you have to be able to use the SNDCTL_DSP_GETxPTR ioctls. But with the current mm, this does not seem to be easy to implement. One cannot simply remember the virtual address at mmap time and then call do_munmap at close time, as the application might already have mapped something different to that address space. Installing specific vm_ops and keeping track of the usage using open/close doesn't seem to work either, as during mmap close (of the last reference) might be followed immediately by a (re)open.
I'm stuck. Can a mm expert enlighten me on how best to implement the unmapping at close time?
Tom
| |