Received: by 10.213.65.68 with SMTP id h4csp892936imn; Tue, 27 Mar 2018 10:42:48 -0700 (PDT) X-Google-Smtp-Source: AIpwx48xm0AvG2Q8qsBQEzjDMzIlnm+DVXIMs+0dn9z4mT3KE08BIZjUbWidAn7yWOCc3yDDCPHI X-Received: by 10.99.127.72 with SMTP id p8mr195441pgn.52.1522172568755; Tue, 27 Mar 2018 10:42:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522172568; cv=none; d=google.com; s=arc-20160816; b=VUAGvygz4WO6Wltwzc5SYX2CpBZ58gcOv2cHykry2N1gC180q260twH7xI7sPzHQ9a sI6ZxaspBk26hvF6GGnGIamJM8TZkMjK5rGGbHGkgEDWwANRZhNTy3Vn5kvEVM6+uzMl xH3fX0amZoqPQ7+eMrKKQflBcmsFDLi5j2jxu8ihzOVmfFlh0Tv+xTum8+G1zqTTkiEH hW5xU9y+2ofjVLQcRjPt6ANFWR3haPD48qGItTCreZUVV9Ejj4e0KAbbw2nHLdqirJ23 JK+IEjtGSMeb/Q1jRqiAbcxXxunhC6Rdm9qQND80lQ7e4pmhmgsTuugQnIuiD8X9+YPE SnwA== 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=a2BUiMoJl6Qt/QZIAFJcLhQPLSj9YogvMwFtw//134M=; b=HxAkXN58JpzlXTEkqXOuvDd5+VR+10wW0y5fh3N/nclihv+CpENV4JtxayVC5JqU2z jBeWPJXVV6SNGF42+uqUu2XMDu278iaqq5578nvyJy1WTP6CFLNzXh3XDayXAPv/uNZt PlbMZzHua55ZBPWTSMLqTpHA43894cAkos56s/bmHpaw4CFIJhLHH/8NKOH+2heY6DqG /C0JiRu1R60laGkwqmJkJEBz0UcoAFJfD4h/vTBSoq8Hh9wXgXZhF8RUDANSVsWOBtUn sCMA+Y9QBLvF/ab15Wdq+wkT99V3LPFl3Motd5GaurmU3E/aoWXHpFGtkUCjXujAjA+B GDaQ== 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 j11-v6si1576307plt.266.2018.03.27.10.42.34; Tue, 27 Mar 2018 10:42:48 -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 S1754098AbeC0Qdz (ORCPT + 99 others); Tue, 27 Mar 2018 12:33:55 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:44084 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751249AbeC0Qdv (ORCPT ); Tue, 27 Mar 2018 12:33:51 -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 46F5111E3; Tue, 27 Mar 2018 16:33:51 +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.14 010/101] ALSA: aloop: Sync stale timer before release Date: Tue, 27 Mar 2018 18:26:42 +0200 Message-Id: <20180327162750.635567497@linuxfoundation.org> X-Mailer: git-send-email 2.16.3 In-Reply-To: <20180327162749.993880276@linuxfoundation.org> References: <20180327162749.993880276@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.14-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);