zsm@: Please analyze and assign back to me if we need to apply patches.

b3defb791b26ea0 ("ALSA: seq: Make ioctls race-free") fixes this issue.

The following versions are affected, but the patch would not cleanly apply as the code seems to have been changed near the ioctl entry point. A similar patch as above that introduces at lock guarding the "p->func(client, arg)" part should work.

4.4, 3.8, 3.18, 3.14, 3.10

The bug is fixed on 4.14.

The bug will be fixed in v4.4.115 with commit e38431ddff0f. Backport comment is as follows.
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
     take the mutex and add ret variable there.]
Let's pick it up with the v4.4.115 merge to avoid merge conflicts. We can then (hopefully) apply the same backport to older kernels.

Waiting for merge of v4.4.115.

v4.4.115 has been released, so we can pick the fix for older kernels while waiting for the merge of v4.4.115 into chromeos-4.4.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/344c58425890e489daceb0428a2484b1dd21e754

commit 344c58425890e489daceb0428a2484b1dd21e754
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Feb 05 20:25:06 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/900842
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zubin Mithra <zsm@chromium.org>

[modify] https://crrev.com/344c58425890e489daceb0428a2484b1dd21e754/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/344c58425890e489daceb0428a2484b1dd21e754/sound/core/seq/seq_clientmgr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f62e46c1390ca683342796a4b4b37c77c258bee8

commit f62e46c1390ca683342796a4b4b37c77c258bee8
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Feb 06 03:09:27 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/900829

[modify] https://crrev.com/f62e46c1390ca683342796a4b4b37c77c258bee8/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/f62e46c1390ca683342796a4b4b37c77c258bee8/sound/core/seq/seq_clientmgr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c63c1027953e1b0fdecf8082f585c12f1ae3c286

commit c63c1027953e1b0fdecf8082f585c12f1ae3c286
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Feb 06 03:08:54 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/900830

[modify] https://crrev.com/c63c1027953e1b0fdecf8082f585c12f1ae3c286/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/c63c1027953e1b0fdecf8082f585c12f1ae3c286/sound/core/seq/seq_clientmgr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7e6d4590f553e9973897af8b347a12337d86f3a4

commit 7e6d4590f553e9973897af8b347a12337d86f3a4
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Feb 06 03:09:03 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/900831

[modify] https://crrev.com/7e6d4590f553e9973897af8b347a12337d86f3a4/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/7e6d4590f553e9973897af8b347a12337d86f3a4/sound/core/seq/seq_clientmgr.c

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2cbe3ef5b8a4202f22b163809a28b63d8ea46081

commit 2cbe3ef5b8a4202f22b163809a28b63d8ea46081
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Feb 07 04:12:27 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/900842
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zubin Mithra <zsm@chromium.org>
(cherry picked from commit 344c58425890e489daceb0428a2484b1dd21e754)
Reviewed-on: https://chromium-review.googlesource.com/902409

[modify] https://crrev.com/2cbe3ef5b8a4202f22b163809a28b63d8ea46081/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/2cbe3ef5b8a4202f22b163809a28b63d8ea46081/sound/core/seq/seq_clientmgr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1ce9bcf7fd4cd7daf7245d227d26ba440e5c7322

commit 1ce9bcf7fd4cd7daf7245d227d26ba440e5c7322
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Feb 07 04:12:29 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/902412

[modify] https://crrev.com/1ce9bcf7fd4cd7daf7245d227d26ba440e5c7322/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/1ce9bcf7fd4cd7daf7245d227d26ba440e5c7322/sound/core/seq/seq_clientmgr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4654af7dca010976e6afc0e92f29a34d2c274715

commit 4654af7dca010976e6afc0e92f29a34d2c274715
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Feb 07 04:12:31 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/902411

[modify] https://crrev.com/4654af7dca010976e6afc0e92f29a34d2c274715/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/4654af7dca010976e6afc0e92f29a34d2c274715/sound/core/seq/seq_clientmgr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9a53f96f55041a7045b2020438f3dd6ff5ffeab7

commit 9a53f96f55041a7045b2020438f3dd6ff5ffeab7
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Feb 07 04:12:32 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/902410

[modify] https://crrev.com/9a53f96f55041a7045b2020438f3dd6ff5ffeab7/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/9a53f96f55041a7045b2020438f3dd6ff5ffeab7/sound/core/seq/seq_clientmgr.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/eccd2b95d155e922341692a8023abcd7873ab050

commit eccd2b95d155e922341692a8023abcd7873ab050
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Feb 07 04:16:44 2018

BACKPORT: ALSA: seq: Make ioctls race-free

commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream.

The ALSA sequencer ioctls have no protection against racy calls while
the concurrent operations may lead to interfere with each other.  As
reported recently, for example, the concurrent calls of setting client
pool with a combination of write calls may lead to either the
unkillable dead-lock or UAF.

As a slightly big hammer solution, this patch introduces the mutex to
make each ioctl exclusive.  Although this may reduce performance via
parallel ioctl calls, usually it's not demanded for sequencer usages,
hence it should be negligible.

BUG= chromium:808786 
TEST=Build and run

Change-Id: Iee3322cb46ff9b8850ffa003912b6ff67da5e14c
Reported-by: Luo Quan <a4651386@163.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 4.4: ioctl dispatch is done from snd_seq_do_ioctl();
 take the mutex and add ret variable there.]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[backport: see 4.4 comments above]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit 623e5c8ae32b39cc8baea83478695dc624935318)
Reviewed-on: https://chromium-review.googlesource.com/900832

[modify] https://crrev.com/eccd2b95d155e922341692a8023abcd7873ab050/sound/core/seq/seq_clientmgr.h
[modify] https://crrev.com/eccd2b95d155e922341692a8023abcd7873ab050/sound/core/seq/seq_clientmgr.c

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot