Synopsis
Applications can mmap sound driver DMA memory into their
address space (see http://www.4front-tech.com for API
documentation). When the application closes the audio fd,
it still has the mapping to the DMA buffer. It can now
interfere with other apps playing/recording audio.
(i.e. the driver should prevent opening the sound driver
again while another app holds mappings open to it)
But there''s a more serious problem: even though the mapping
still exists, the reference count of the sound module
has dropped to 0, thus allowing it to be removed
either by explicit rmmod or by kerneld. The sound driver then
frees the DMA buffer memory, but the application still has
the mapping to that memory. But since the memory is now considered
free, nothing prevents it from being reused for an arbitrary kernel
data structure. That way, the application can overwrite kernel
memory.
I have no idea whether commercial OSS is affected too,
so I would like to hear reports on that.
Solution
It has been fixed in Linux Kernel 2.1.89
Work around
Either don''t allow untrusted users access to the sound device
(by setting permission on /etc/dsp* accordingly), or
don''t demand load sound by kerneld, that is either compile
it statically into the kernel or load it manually by modprobe.
I''ve appended a simple test case to illustrate the problem.
It doesn''t do any harm in the form appended, but can be easily
modified to do so.
Tom
