From patchwork Thu Dec 15 11:08:47 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Henriques X-Patchwork-Id: 706038 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3tfW0b3XPwz9snm; Thu, 15 Dec 2016 22:09:03 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.76) (envelope-from ) id 1cHTuH-0002ct-F1; Thu, 15 Dec 2016 11:09:01 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtp (Exim 4.76) (envelope-from ) id 1cHTu5-0002YK-UC for kernel-team@lists.ubuntu.com; Thu, 15 Dec 2016 11:08:49 +0000 Received: from 1.general.henrix.uk.vpn ([10.172.192.212] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1cHTu5-0005yN-Hc for kernel-team@lists.ubuntu.com; Thu, 15 Dec 2016 11:08:49 +0000 From: Luis Henriques To: kernel-team@lists.ubuntu.com Subject: [precise, trusty, vivid] ALSA: pcm : Call kill_fasync() in stream lock Date: Thu, 15 Dec 2016 11:08:47 +0000 Message-Id: <1481800128-20326-2-git-send-email-luis.henriques@canonical.com> In-Reply-To: <1481800128-20326-1-git-send-email-luis.henriques@canonical.com> References: <1481800128-20326-1-git-send-email-luis.henriques@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.14 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: kernel-team-bounces@lists.ubuntu.com From: Takashi Iwai Currently kill_fasync() is called outside the stream lock in snd_pcm_period_elapsed(). This is potentially racy, since the stream may get released even during the irq handler is running. Although snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't guarantee that the irq handler finishes, thus the kill_fasync() call outside the stream spin lock may be invoked after the substream is detached, as recently reported by KASAN. As a quick workaround, move kill_fasync() call inside the stream lock. The fasync is rarely used interface, so this shouldn't have a big impact from the performance POV. Ideally, we should implement some sync mechanism for the proper finish of stream and irq handler. But this oneliner should suffice for most cases, so far. Reported-by: Baozeng Ding Signed-off-by: Takashi Iwai CVE-2016-9794 (backported from commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4) [ luis: used Takashi's backport for upstream stable 3.12 ] Signed-off-by: Luis Henriques Acked-by: Colin Ian King --- sound/core/pcm_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 7f00d34f0abd..dfbca788fbbc 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1766,10 +1766,10 @@ void snd_pcm_period_elapsed(struct snd_pcm_substream *substream) if (substream->timer_running) snd_timer_interrupt(substream->timer, 1); _end: + kill_fasync(&runtime->fasync, SIGIO, POLL_IN); snd_pcm_stream_unlock_irqrestore(substream, flags); if (runtime->transfer_ack_end) runtime->transfer_ack_end(substream); - kill_fasync(&runtime->fasync, SIGIO, POLL_IN); } EXPORT_SYMBOL(snd_pcm_period_elapsed);