Issue metadata
Sign in to add a comment
|
CVE-2018-7566 CrOS: Vulnerability reported in Linux kernel |
||||||||||||||||||||||
Issue descriptionVOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. Advisory: CVE-2018-7566 Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2018-7566 CVSS severity score: 4.6/10.0 Description: The Linux kernel 4.15 has a Buffer Overflow via an SNDRV_SEQ_IOCTL_SET_CLIENT_POOL ioctl write operation to /dev/snd/seq by a local user. This bug was filed by http://go/vomit Please contact us at vomit-team@google.com if you need any assistance.
,
Apr 19 2018
,
Apr 19 2018
,
Apr 19 2018
,
Apr 19 2018
,
Apr 19 2018
The upstream commit hashes are :-
- d85739367c6("ALSA: seq: Don't allow resizing pool in use")
- 7bd80091567("ALSA: seq: More protection for concurrent write and ioctl races")
,
Apr 19 2018
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fb06ed187afa6e8adbce844ef2ded6745c5d44d8 commit fb06ed187afa6e8adbce844ef2ded6745c5d44d8 Author: Takashi Iwai <tiwai@suse.de> Date: Fri Apr 20 02:28:48 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019391 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/fb06ed187afa6e8adbce844ef2ded6745c5d44d8/sound/core/seq/seq_clientmgr.c
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/70a45c0200e3436587ed1a698927a387bbff1a7c commit 70a45c0200e3436587ed1a698927a387bbff1a7c Author: Takashi Iwai <tiwai@suse.de> Date: Fri Apr 20 02:28:50 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019392 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/70a45c0200e3436587ed1a698927a387bbff1a7c/sound/core/seq/seq_clientmgr.c
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9966e5d7ee37348c1fb939a34ed1147fdf54d7c3 commit 9966e5d7ee37348c1fb939a34ed1147fdf54d7c3 Author: Takashi Iwai <tiwai@suse.de> Date: Fri Apr 20 02:28:52 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None CQ-DEPEND=CL:1019392 Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019393 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/9966e5d7ee37348c1fb939a34ed1147fdf54d7c3/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/9966e5d7ee37348c1fb939a34ed1147fdf54d7c3/sound/core/seq/seq_memory.h [modify] https://crrev.com/9966e5d7ee37348c1fb939a34ed1147fdf54d7c3/sound/core/seq/seq_fifo.c [modify] https://crrev.com/9966e5d7ee37348c1fb939a34ed1147fdf54d7c3/sound/core/seq/seq_memory.c
,
Apr 23 2018
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/be08c70b2aeef738266edc93308ee1bc5d4ce1cc commit be08c70b2aeef738266edc93308ee1bc5d4ce1cc Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:14 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019544 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/be08c70b2aeef738266edc93308ee1bc5d4ce1cc/sound/core/seq/seq_clientmgr.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f8cfa21d87bc49a8516ae993924f98f34631691a commit f8cfa21d87bc49a8516ae993924f98f34631691a Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:16 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019545 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/f8cfa21d87bc49a8516ae993924f98f34631691a/sound/core/seq/seq_clientmgr.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1e3ab73eb8eee74963cb4e0894455e8a6bded7ca commit 1e3ab73eb8eee74963cb4e0894455e8a6bded7ca Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:18 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019546 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/1e3ab73eb8eee74963cb4e0894455e8a6bded7ca/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/1e3ab73eb8eee74963cb4e0894455e8a6bded7ca/sound/core/seq/seq_memory.h [modify] https://crrev.com/1e3ab73eb8eee74963cb4e0894455e8a6bded7ca/sound/core/seq/seq_fifo.c [modify] https://crrev.com/1e3ab73eb8eee74963cb4e0894455e8a6bded7ca/sound/core/seq/seq_memory.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/746b1b3ecd93783201c6dbcd9fa9159754aaecee commit 746b1b3ecd93783201c6dbcd9fa9159754aaecee Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:20 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019560 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/746b1b3ecd93783201c6dbcd9fa9159754aaecee/sound/core/seq/seq_clientmgr.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a93546ebe0ba377c58bf5ea62e2ba6dc71b7408f commit a93546ebe0ba377c58bf5ea62e2ba6dc71b7408f Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:23 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019561 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/a93546ebe0ba377c58bf5ea62e2ba6dc71b7408f/sound/core/seq/seq_clientmgr.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c89c2a89f730e7288a27946a1256283c265cf4d9 commit c89c2a89f730e7288a27946a1256283c265cf4d9 Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:25 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019562 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/c89c2a89f730e7288a27946a1256283c265cf4d9/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/c89c2a89f730e7288a27946a1256283c265cf4d9/sound/core/seq/seq_memory.h [modify] https://crrev.com/c89c2a89f730e7288a27946a1256283c265cf4d9/sound/core/seq/seq_fifo.c [modify] https://crrev.com/c89c2a89f730e7288a27946a1256283c265cf4d9/sound/core/seq/seq_memory.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/34928a9c8a754fd09e0320b296b272bad4a06ff6 commit 34928a9c8a754fd09e0320b296b272bad4a06ff6 Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:07 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019564 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/34928a9c8a754fd09e0320b296b272bad4a06ff6/sound/core/seq/seq_clientmgr.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5dc23e67fa46d508d89bfc393c937d637cbeb1ed commit 5dc23e67fa46d508d89bfc393c937d637cbeb1ed Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:09 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019565 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/5dc23e67fa46d508d89bfc393c937d637cbeb1ed/sound/core/seq/seq_clientmgr.c
,
Apr 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9de37119845359814588ee533d8bfec182980f42 commit 9de37119845359814588ee533d8bfec182980f42 Author: Takashi Iwai <tiwai@suse.de> Date: Mon Apr 23 22:36:12 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019566 Reviewed-by: Guenter Roeck <groeck@chromium.org> [modify] https://crrev.com/9de37119845359814588ee533d8bfec182980f42/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/9de37119845359814588ee533d8bfec182980f42/sound/core/seq/seq_memory.h [modify] https://crrev.com/9de37119845359814588ee533d8bfec182980f42/sound/core/seq/seq_fifo.c [modify] https://crrev.com/9de37119845359814588ee533d8bfec182980f42/sound/core/seq/seq_memory.c
,
Apr 24 2018
Your change meets the bar and is auto-approved for M67. Please go ahead and merge the CL to branch 3396 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c44e30507c47ecd7b8a4aba49eb0ff7abd6307d7 commit c44e30507c47ecd7b8a4aba49eb0ff7abd6307d7 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:16 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019560 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 746b1b3ecd93783201c6dbcd9fa9159754aaecee) Reviewed-on: https://chromium-review.googlesource.com/1025377 [modify] https://crrev.com/c44e30507c47ecd7b8a4aba49eb0ff7abd6307d7/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/19faaaeaf372376d2ba6edaac1b3dcc9f7c15513 commit 19faaaeaf372376d2ba6edaac1b3dcc9f7c15513 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:18 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019544 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit be08c70b2aeef738266edc93308ee1bc5d4ce1cc) Reviewed-on: https://chromium-review.googlesource.com/1026255 [modify] https://crrev.com/19faaaeaf372376d2ba6edaac1b3dcc9f7c15513/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b6c4cfefbdca039374719f2ff5a261a70e041c3d commit b6c4cfefbdca039374719f2ff5a261a70e041c3d Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:19 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019545 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit f8cfa21d87bc49a8516ae993924f98f34631691a) Reviewed-on: https://chromium-review.googlesource.com/1026133 [modify] https://crrev.com/b6c4cfefbdca039374719f2ff5a261a70e041c3d/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ee84abc8d321cd5c6593b1634ff72e81524202b6 commit ee84abc8d321cd5c6593b1634ff72e81524202b6 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:20 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019561 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit a93546ebe0ba377c58bf5ea62e2ba6dc71b7408f) Reviewed-on: https://chromium-review.googlesource.com/1025378 [modify] https://crrev.com/ee84abc8d321cd5c6593b1634ff72e81524202b6/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1007b137617183c52f2482ba557b488525463966 commit 1007b137617183c52f2482ba557b488525463966 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:22 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019564 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 34928a9c8a754fd09e0320b296b272bad4a06ff6) Reviewed-on: https://chromium-review.googlesource.com/1025023 [modify] https://crrev.com/1007b137617183c52f2482ba557b488525463966/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e4bc8f2e48bc630aaa48f306f4f0643636296b22 commit e4bc8f2e48bc630aaa48f306f4f0643636296b22 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:23 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019565 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 5dc23e67fa46d508d89bfc393c937d637cbeb1ed) Reviewed-on: https://chromium-review.googlesource.com/1025024 [modify] https://crrev.com/e4bc8f2e48bc630aaa48f306f4f0643636296b22/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c5144435bb8471d2dd8692bce4d39e56a7effa42 commit c5144435bb8471d2dd8692bce4d39e56a7effa42 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:24 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019562 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit c89c2a89f730e7288a27946a1256283c265cf4d9) Reviewed-on: https://chromium-review.googlesource.com/1025379 [modify] https://crrev.com/c5144435bb8471d2dd8692bce4d39e56a7effa42/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/c5144435bb8471d2dd8692bce4d39e56a7effa42/sound/core/seq/seq_memory.h [modify] https://crrev.com/c5144435bb8471d2dd8692bce4d39e56a7effa42/sound/core/seq/seq_fifo.c [modify] https://crrev.com/c5144435bb8471d2dd8692bce4d39e56a7effa42/sound/core/seq/seq_memory.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/56c195485f0c7e8cc58188fee8259436e8a92feb commit 56c195485f0c7e8cc58188fee8259436e8a92feb Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:25 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019546 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 1e3ab73eb8eee74963cb4e0894455e8a6bded7ca) Reviewed-on: https://chromium-review.googlesource.com/1026134 [modify] https://crrev.com/56c195485f0c7e8cc58188fee8259436e8a92feb/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/56c195485f0c7e8cc58188fee8259436e8a92feb/sound/core/seq/seq_memory.h [modify] https://crrev.com/56c195485f0c7e8cc58188fee8259436e8a92feb/sound/core/seq/seq_fifo.c [modify] https://crrev.com/56c195485f0c7e8cc58188fee8259436e8a92feb/sound/core/seq/seq_memory.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f03cd4347e2d57140f72ccb42fddad4f3db92470 commit f03cd4347e2d57140f72ccb42fddad4f3db92470 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:45:26 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019566 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 9de37119845359814588ee533d8bfec182980f42) Reviewed-on: https://chromium-review.googlesource.com/1024597 [modify] https://crrev.com/f03cd4347e2d57140f72ccb42fddad4f3db92470/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/f03cd4347e2d57140f72ccb42fddad4f3db92470/sound/core/seq/seq_memory.h [modify] https://crrev.com/f03cd4347e2d57140f72ccb42fddad4f3db92470/sound/core/seq/seq_fifo.c [modify] https://crrev.com/f03cd4347e2d57140f72ccb42fddad4f3db92470/sound/core/seq/seq_memory.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a0d2b49727f20072ee6b5462a56013e43e892e7c commit a0d2b49727f20072ee6b5462a56013e43e892e7c Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:48:40 2018 UPSTREAM: ALSA: seq: Fix racy pool initializations ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. BUG= 834716 TEST=None Change-Id: I0b860d7053332c89f02f988823b87d01d2e3170f Reported-by: <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d15d662e89fc667b90cd294b0eb45694e33144da) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019391 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit fb06ed187afa6e8adbce844ef2ded6745c5d44d8) Reviewed-on: https://chromium-review.googlesource.com/1026370 [modify] https://crrev.com/a0d2b49727f20072ee6b5462a56013e43e892e7c/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ce637a254e8e85057021faeefca8a4b4ab5c0ca3 commit ce637a254e8e85057021faeefca8a4b4ab5c0ca3 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:48:42 2018 UPSTREAM: ALSA: seq: Don't allow resizing pool in use This is a fix for a (sort of) fallout in the recent commit d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for CVE-2018-1000004. As the pool resize deletes the existing cells, it may lead to a race when another thread is writing concurrently, eventually resulting a UAF. A simple workaround is not to allow the pool resizing when the pool is in use. It's an invalid behavior in anyway. BUG= 834716 TEST=None Change-Id: Ic2b9cb355273a12cd8657fe2d57ce8641edcbc1c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit d85739367c6d56e475c281945c68fdb05ca74b4c) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019392 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 70a45c0200e3436587ed1a698927a387bbff1a7c) Reviewed-on: https://chromium-review.googlesource.com/1026371 [modify] https://crrev.com/ce637a254e8e85057021faeefca8a4b4ab5c0ca3/sound/core/seq/seq_clientmgr.c
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ef3977a4c213b0a5fdb9a4fc74bd47a8841aaf42 commit ef3977a4c213b0a5fdb9a4fc74bd47a8841aaf42 Author: Takashi Iwai <tiwai@suse.de> Date: Tue Apr 24 18:48:43 2018 UPSTREAM: ALSA: seq: More protection for concurrent write and ioctl races This patch is an attempt for further hardening against races between the concurrent write and ioctls. The previous fix d15d662e89fc ("ALSA: seq: Fix racy pool initializations") covered the race of the pool initialization at writer and the pool resize ioctl by the client->ioctl_mutex (CVE-2018-1000004). However, basically this mutex should be applied more widely to the whole write operation for avoiding the unexpected pool operations by another thread. The only change outside snd_seq_write() is the additional mutex argument to helper functions, so that we can unlock / relock the given mutex temporarily during schedule() call for blocking write. BUG= 834716 TEST=None Change-Id: I0a61b4fe60d1b01d7459aefe6572fdf75e7c988c Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations") Reported-by: <long7573@126.com> Reported-by: Nicolai Stange <nstange@suse.de> Reviewed-and-tested-by: Nicolai Stange <nstange@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit 7bd80091567789f1c0cb70eb4737aac8bcd2b6b9) Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1019393 Reviewed-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 9966e5d7ee37348c1fb939a34ed1147fdf54d7c3) Reviewed-on: https://chromium-review.googlesource.com/1026372 [modify] https://crrev.com/ef3977a4c213b0a5fdb9a4fc74bd47a8841aaf42/sound/core/seq/seq_clientmgr.c [modify] https://crrev.com/ef3977a4c213b0a5fdb9a4fc74bd47a8841aaf42/sound/core/seq/seq_memory.h [modify] https://crrev.com/ef3977a4c213b0a5fdb9a4fc74bd47a8841aaf42/sound/core/seq/seq_fifo.c [modify] https://crrev.com/ef3977a4c213b0a5fdb9a4fc74bd47a8841aaf42/sound/core/seq/seq_memory.c
,
Apr 24 2018
,
Apr 25 2018
,
Aug 1
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 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by zsm@chromium.org
, Apr 19 2018Owner: zsm@chromium.org
Status: Assigned (was: Untriaged)
The patch is d15d662e89fc("ALSA: seq: Fix racy pool initializations"). The following patches are also related :- - d9c724729d0("ALSA: seq: Don't allow resizing pool in use") - 6d3a7dcba8c("ALSA: seq: More protection for concurrent write and ioctl races") The patches are present in 4.14, 4.4. The patches are not present in 3.18, 3.14, 3.10, 3.8