Received: by 10.213.65.68 with SMTP id h4csp919678imn; Tue, 27 Mar 2018 11:12:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/hi5+3wEViQIz1mlsFWQ3E8Rsf0OIowmc1nUjA8AE8AgJfSnS4rmlM0Wxhe5LtjtXY+rPN X-Received: by 10.98.210.7 with SMTP id c7mr292873pfg.92.1522174332036; Tue, 27 Mar 2018 11:12:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522174332; cv=none; d=google.com; s=arc-20160816; b=hZ9s8TnPihZqEfadOxxImOc07yAv1NdJTtIWOAVwwQIE36tVtxPherMHM35PlIaAFS lGAbMrTYq3N8C8ViBLMs2eyScB2ljgqIE9XfMiGMrVbIqso5BDRbtfdYwVmnqPc5M2sG S04IZAIjruyLmO+5kdiNqmOPyhVhGSvuJEqvOBJDpzgK37mFr7I0fMh8vp+9S/T8Kh/4 OSKeirlbA7crjqBMwH2mGSx208EtK+MDC6LHNp8LxW7TbIiGfGPWkM+5dpIUauAZIYt7 ZHLZ6xUAnu+ocE6Ekxq36yTAmOyGwwZNWuoY9/zZiwTS99evXgLraRiL0hlydLi85/i2 C+qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=ohxNuN9eWibl22URVdCOZUeTQXtG8kwobBINL46jlwc=; b=KVzLXxnmMS7YzNPQA4mOxLhZSX9RNqFnmGjYaM34Opi6zTU3mRtgYGvOcBiayz8Ea3 jinOZC3//J/fXDytTmPREKxs5eKVOnti6JCrq7cR1F5hQ/NdjogcPbkNyuv3y4Oi8SGk Q/W000UCLdcLIFqkUcmly2KQmUhXfhTbw2amtc/HrR71BXIENaYOAsQ+dyIoevFgApMz uftYUNnDmaHPvMzdFIxlHevC4DrjRHa7I5uzLg+hgxmlCiLqXmh7oTzyBeup1dl4YzBM 2mPwI/V+uCarnjSFFnv3X1a0lqo0MrE+t7ThfhoAR0K7STEXbBtmuiTV7iLGB+P26RCM qUKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6-v6si1765635plf.70.2018.03.27.11.11.57; Tue, 27 Mar 2018 11:12:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbeC0Q2t (ORCPT + 99 others); Tue, 27 Mar 2018 12:28:49 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:40958 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbeC0Q2r (ORCPT ); Tue, 27 Mar 2018 12:28:47 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 5C59D103A; Tue, 27 Mar 2018 16:28:46 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Takashi Iwai Subject: [PATCH 4.4 04/43] ALSA: aloop: Sync stale timer before release Date: Tue, 27 Mar 2018 18:27:08 +0200 Message-Id: <20180327162716.638981112@linuxfoundation.org> X-Mailer: git-send-email 2.16.3 In-Reply-To: <20180327162716.407986916@linuxfoundation.org> References: <20180327162716.407986916@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai commit 67a01afaf3d34893cf7d2ea19b34555d6abb7cb0 upstream. The aloop driver tries to stop the pending timer via timer_del() in the trigger callback and in the close callback. The former is correct, as it's an atomic operation, while the latter expects that the timer gets really removed and proceeds the resource releases after that. But timer_del() doesn't synchronize, hence the running timer may still access the released resources. A similar situation can be also seen in the prepare callback after trigger(STOP) where the prepare tries to re-initialize the things while a timer is still running. The problems like the above are seen indirectly in some syzkaller reports (although it's not 100% clear whether this is the only cause, as the race condition is quite narrow and not always easy to trigger). For addressing these issues, this patch adds the explicit alls of timer_del_sync() in some places, so that the pending timer is properly killed / synced. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/drivers/aloop.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -192,6 +192,11 @@ static inline void loopback_timer_stop(s dpcm->timer.expires = 0; } +static inline void loopback_timer_stop_sync(struct loopback_pcm *dpcm) +{ + del_timer_sync(&dpcm->timer); +} + #define CABLE_VALID_PLAYBACK (1 << SNDRV_PCM_STREAM_PLAYBACK) #define CABLE_VALID_CAPTURE (1 << SNDRV_PCM_STREAM_CAPTURE) #define CABLE_VALID_BOTH (CABLE_VALID_PLAYBACK|CABLE_VALID_CAPTURE) @@ -326,6 +331,8 @@ static int loopback_prepare(struct snd_p struct loopback_cable *cable = dpcm->cable; int bps, salign; + loopback_timer_stop_sync(dpcm); + salign = (snd_pcm_format_width(runtime->format) * runtime->channels) / 8; bps = salign * runtime->rate; @@ -745,7 +752,7 @@ static int loopback_close(struct snd_pcm struct loopback *loopback = substream->private_data; struct loopback_pcm *dpcm = substream->runtime->private_data; - loopback_timer_stop(dpcm); + loopback_timer_stop_sync(dpcm); mutex_lock(&loopback->cable_lock); free_cable(substream); mutex_unlock(&loopback->cable_lock);