Received: by 10.192.165.148 with SMTP id m20csp2477367imm; Sun, 22 Apr 2018 07:52:24 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+OXl4v8Y/0ssfhR1ckzxvG1r13CXCulsMf04GJCvjoJKdHIEt3nyGa6Q8RiLeEGU7V3kP0 X-Received: by 2002:a17:902:8b84:: with SMTP id ay4-v6mr17553988plb.57.1524408744706; Sun, 22 Apr 2018 07:52:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524408744; cv=none; d=google.com; s=arc-20160816; b=RqoYldFhEwp9a3uSWBVTx4DSm3VASOUGn5TmLfMn7Fw83a26Au53+s/iQWg/NbhtV2 jz3c/XT/QZUW/ri/TAKpS9SfATBJUcVjp5HFPbRzeSqp8eHr0E9eZMYKEVBn2xgdpcZ8 5ha1Cim5pcE2BCtZgoNex2pWq4ggZAJKqesypIvFhRRXULlWixyZ/odiXkiwhftcDMLr sbGnuisSHEmCSEvo9AY4TH/CYGTq624ANVLN2sRexIHPcNuW/ip4Ml2fAC2TWEqSHFLo yDwS9agAamKIXasYnDiTikIBXrWb/6ct9PckR7RNUvA5po6XhaCYO+u1xrYvBPGscZNo 0EfA== 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=YFLrAMxVFvCbMs+e66+uFg7uGlCu6WQuRKKWE1Dpyqs=; b=UbwldPxf28DCgoI0kSlz3AsQMA35VBbQnwCqxzAk1fwwo7mdVvUlyGZYPULdcIAlB+ cpLOdOLMr1tACgXeNtWFBxMxhJtIVMZFH4kfDWjxgOP2elIfQkrqpIqhHwWatGI7vgNy 7jPte/F+coQRC31JgeAoDplk6Bukd0Jeo++ak8bxSCJaFNtfRHidJrCwbgbmxwF6M9oy arGXCWmKXurslsSvCXgzL7xdomeq61cuOu/QURD9uABE6v1olk45GbeaDHyWkwfPzqM3 Jf+8LWHSMcYrooSMEAwJEDMMBvEyjv7LNqEIOgcvzQlaqoOVs/RDOq7qtzQajcnZKCFy GOiw== 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 q1si8495859pgp.370.2018.04.22.07.52.10; Sun, 22 Apr 2018 07:52:24 -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 S1757414AbeDVOu7 (ORCPT + 99 others); Sun, 22 Apr 2018 10:50:59 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:56726 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932130AbeDVOPL (ORCPT ); Sun, 22 Apr 2018 10:15:11 -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 B6DD2978; Sun, 22 Apr 2018 14:15:10 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+150189c103427d31a053@syzkaller.appspotmail.com, syzbot+7e3f31a52646f939c052@syzkaller.appspotmail.com, syzbot+4f2016cf5185da7759dc@syzkaller.appspotmail.com, Takashi Iwai Subject: [PATCH 4.9 64/95] ALSA: pcm: Fix endless loop for XRUN recovery in OSS emulation Date: Sun, 22 Apr 2018 15:53:33 +0200 Message-Id: <20180422135213.044412251@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180422135210.432103639@linuxfoundation.org> References: <20180422135210.432103639@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.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai commit e15dc99dbb9cf99f6432e8e3c0b3a8f7a3403a86 upstream. The commit 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") split the PCM preparation code to a locked version, and it added a sanity check of runtime->oss.prepare flag along with the change. This leaded to an endless loop when the stream gets XRUN: namely, snd_pcm_oss_write3() and co call snd_pcm_oss_prepare() without setting runtime->oss.prepare flag and the loop continues until the PCM state reaches to another one. As the function is supposed to execute the preparation unconditionally, drop the invalid state check there. The bug was triggered by syzkaller. Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") Reported-by: syzbot+150189c103427d31a053@syzkaller.appspotmail.com Reported-by: syzbot+7e3f31a52646f939c052@syzkaller.appspotmail.com Reported-by: syzbot+4f2016cf5185da7759dc@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/core/oss/pcm_oss.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1139,13 +1139,14 @@ static int snd_pcm_oss_get_active_substr } /* call with params_lock held */ +/* NOTE: this always call PREPARE unconditionally no matter whether + * runtime->oss.prepare is set or not + */ static int snd_pcm_oss_prepare(struct snd_pcm_substream *substream) { int err; struct snd_pcm_runtime *runtime = substream->runtime; - if (!runtime->oss.prepare) - return 0; err = snd_pcm_kernel_ioctl(substream, SNDRV_PCM_IOCTL_PREPARE, NULL); if (err < 0) { pcm_dbg(substream->pcm,