ALSA: seq: Protect in-kernel ioctl calls with mutex

[ Upstream commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32 ]

ALSA OSS sequencer calls the ioctl function indirectly via
snd_seq_kernel_client_ctl().  While we already applied the protection
against races between the normal ioctls and writes via the client's
ioctl_mutex, this code path was left untouched.  And this seems to be
the cause of still remaining some rare UAF as spontaneously triggered
by syzkaller.

For the sake of robustness, wrap the ioctl_mutex also for the call via
snd_seq_kernel_client_ctl(), too.

Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index b55cb96d1fed4d8a553977bbd5fbee6c8f3e40f8..40ae8f67efdea86d8e96a3a900d2cf2f37a47bbb 100644 (file)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -2343,14 +2343,19 @@ int snd_seq_kernel_client_ctl(int clientid, unsigned int cmd, void *arg)
 {
        const struct ioctl_handler *handler;
        struct snd_seq_client *client;
+       int err;
 
        client = clientptr(clientid);
        if (client == NULL)
                return -ENXIO;
 
        for (handler = ioctl_handlers; handler->cmd > 0; ++handler) {
-               if (handler->cmd == cmd)
-                       return handler->func(client, arg);
+               if (handler->cmd == cmd) {
+                       mutex_lock(&client->ioctl_mutex);
+                       err = handler->func(client, arg);
+                       mutex_unlock(&client->ioctl_mutex);
+                       return err;
+               }
        }
 
        pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",