Received: by 10.213.65.68 with SMTP id h4csp870521imn; Tue, 27 Mar 2018 10:17:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx48vnlBssMMHW8OpgOlUsi1q+t9BTV+QkzUnRdwks5qh7bcggiduX5GdxScpbAuWL/FUux5q X-Received: by 2002:a17:902:6a17:: with SMTP id m23-v6mr174142plk.342.1522171032397; Tue, 27 Mar 2018 10:17:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522171032; cv=none; d=google.com; s=arc-20160816; b=sDCHzMIErasnHZPLpnMvWfn6xnUJ83cNVnO15TX8uzzcFgdtyyavQwGS0VhYL6EmE4 b1IOyhaqTpAHDbKdSYe23PUVEgPEL3xVzJC/PT+A0IcnfTsz9ua1XCQs4wsccOJpzdpq LjUOEieUvcuhIVVMHDwHlXayRKp27JlIu4zf2yyOwHDcA8TCeuJVk7b+rs0AX4BVZc6q BoiMwq7TU9ZdxzWEpPYl98xAfVGqrI2AeLbXZbj+drZKrZgiidgRxI0Y6V2iCAomFFPo Po+xxbQBLSOhiff2e4vKv/MOfRDSsWJol106I+xCbQ9GaLImIh/bZNNdINt7OmpBvMGk +LAQ== 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=mAaxx8W25p2iwaZKkMfJeTbRIoaKotYPqaKBRuzs5bI=; b=H3tWjA/juyYo9jdNnpSv1VTmEtTTLqstTj73boqs6t3/YFhRjlDtdVCzhqxF5H06qs i18jhOm+SCwnTGUXAsa44zE+CjZFidE4Y1cak3O1ptzSeCBUpHfZedvS1jyCqxjE5lCq QUvwAFbKh+M9JoYyfL1X3We+D/4HfBaCMpQpHNxmSpk03VmqhneAle5gQ07ijFxLyw33 6r4PTBS9gkfp94xE2k2eRlRyc8hTBVPgcVgg0+A6tlWm/MYexCcODwtYq1rRpsk7rhjV 2uxotFLCkEbZ+JxJ8nPLNy982bfLnF3e5JLy2crouCsO/hRj8bPvRQwS+pjGu5H68Pvj 2tyQ== 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 x9-v6si1711050plo.41.2018.03.27.10.16.58; Tue, 27 Mar 2018 10:17: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 S1752706AbeC0RQK (ORCPT + 99 others); Tue, 27 Mar 2018 13:16:10 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46908 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755284AbeC0Qip (ORCPT ); Tue, 27 Mar 2018 12:38:45 -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 20DDC1034; Tue, 27 Mar 2018 16:38:44 +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.15 010/105] ALSA: aloop: Sync stale timer before release Date: Tue, 27 Mar 2018 18:26:50 +0200 Message-Id: <20180327162758.275427660@linuxfoundation.org> X-Mailer: git-send-email 2.16.3 In-Reply-To: <20180327162757.813009222@linuxfoundation.org> References: <20180327162757.813009222@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.15-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; @@ -744,7 +751,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);