Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2432392imm; Thu, 7 Jun 2018 10:28:13 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJDdBGEP1AyxXSHO3rCdVOwc3A/gfWDetVJT0Bcne3kEa3U2lvPkaDBVeXoqlsx1z5ZLM5j X-Received: by 2002:a65:538f:: with SMTP id x15-v6mr2331325pgq.306.1528392492989; Thu, 07 Jun 2018 10:28:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528392492; cv=none; d=google.com; s=arc-20160816; b=IoOh9uXMcqLf3IQW9bemKl0kjXzjGOvC/jszPMpKfc4PIL2a0uEetOx2IcsAWgYZ7p YO2sCIP3k7OOWLCWAHoA0CrvwFr68eDBzkkHHzdzdkK42pMUrqXcwWrUFKmvDEbuSHsX Tj+OhquvKKLnPsESnSmtNR4IVPuZK0vIAfXbaTtoJ2vVdUG+NwAzAGyI7nypn7JpOcw/ t41BWJoZJPm8h+9qSFHt87bXI5/Kaq1dg3YcLedv5D8DPfzGeW2qRuuw1pewo/odg0Xv 1NWkijTDpQBxKwchRURu4sUY/gCoh6Bnv4HxcaK642FLZ+H49JVuK3/Ha7gtcsjg3hDG TdTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=eiQeeDs91BnjIorTao/XFmKqCTIHa/lcU8mJgR2rgrk=; b=xD6EqeHz5ZEdl5qLu0y+2BLfFV2o+UHAIMBNpYg7s7btrdmLEyM97guFfUAK8wd8Lb 4QZ/MglwjNt32b6gtpHPzi8VuS7kmvLzuQNMpfRlj4UExkLP12Se64DTcy7rLMKNrksN LqVPIlRxD8ZYas5rvuExVv9MWFc9/R7Oqr1wAbcvXgC52T9FecgkcqxI4zhicxNrB8/U J7WWtpgp+uWZJloVXnbhyqjYkg8NnehRsrzfAKeYFi6S4VI5EtrgD52+RcHMuzjGEmyh kkSghu2EtXCrKx8gv6ApmAyxyx2Lt/g5LolObKumy4OYYp4s1XwBU6KsBO1Qx7AKLgkS rYIQ== 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 127-v6si54653423pfe.49.2018.06.07.10.27.58; Thu, 07 Jun 2018 10:28: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 S933975AbeFGOeO (ORCPT + 99 others); Thu, 7 Jun 2018 10:34:14 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:40341 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933937AbeFGOeL (ORCPT ); Thu, 7 Jun 2018 10:34:11 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvbM-0005hK-7f; Thu, 07 Jun 2018 15:09:20 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvbE-0003I3-67; Thu, 07 Jun 2018 15:09:12 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Takashi Iwai" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 387/410] ALSA: aloop: Sync stale timer before release In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 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. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings --- sound/drivers/aloop.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -193,6 +193,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) @@ -327,6 +332,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; @@ -746,7 +753,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);