[xenial] ALSA: pcm : Call kill_fasync() in stream lock

From: Takashi Iwai <tiwai@suse.de>

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 <sploving1@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CVE-2016-9794
(cherry picked from commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4)
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
---
 sound/core/pcm_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 15/12/16 11:08, Luis Henriques wrote:
> From: Takashi Iwai <tiwai@suse.de>
> 
> 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 <sploving1@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> CVE-2016-9794
> (cherry picked from commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4)
> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
> ---
>  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 3a9b66c6e09c..0aca39762ed0 100644
> --- a/sound/core/pcm_lib.c
> +++ b/sound/core/pcm_lib.c
> @@ -1886,8 +1886,8 @@ void snd_pcm_period_elapsed(struct snd_pcm_substream *substream)
>  		snd_timer_interrupt(substream->timer, 1);
>  #endif
>   _end:
> -	snd_pcm_stream_unlock_irqrestore(substream, flags);
>  	kill_fasync(&runtime->fasync, SIGIO, POLL_IN);
> +	snd_pcm_stream_unlock_irqrestore(substream, flags);
>  }
>  
>  EXPORT_SYMBOL(snd_pcm_period_elapsed);
> 
Looks sane to me.

Acked-by: Colin Ian King <colin.king@canonical.com>

ACK.