Received: by 10.192.165.148 with SMTP id m20csp2530319imm; Sun, 22 Apr 2018 08:59:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+LN9TEZEA1emyvwbSIc2JGb/7Y5zeIHjXIcIFpaviy9jrcbv9pMaAsci90OWBX8JHq1x9K X-Received: by 10.101.66.6 with SMTP id c6mr14472670pgq.133.1524412741992; Sun, 22 Apr 2018 08:59:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524412741; cv=none; d=google.com; s=arc-20160816; b=qqHTCKVYAAR6RwDqqy2o+HlNEk6IGJbHjPDnIVOItk/YtDRw7PGocbQLBF4MKFwrZB xQGWe/Af2dRccbExiqJeq+cNvc41ZpIeiATwnm6BIteiDDoab9+vnVMrmmdKr0rDsf+e 1fi9NyvX3qKtXHl6Tl8gOEd8Rf1rDHD3ku/l7ukdw5quZ/mKK6ZbN21ICYEN1KsdR+bX llKLh6awhw+lPzd/dygx4TyhzcbYqUMma11LxnTvi+a1Ai7YUSv2zVZZObOQD/5VOysr GwhDK/QupI2QQrNxXr0gJ3QmYHelsyg3mYRssccPG2BeDAb3LEuVeR0aptuwzudrOGEZ y3mQ== 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=1xXTowv0GVTbTuRSpKRtaTedE2ZQUrEYPFfD64lL6FU=; b=JDWjJXXt23ckXIz/k9JfV/TUvM7XtSvvk4ZlyGWTpD5HvJXi/8/u2U0CZ3rO5v8FRk KEshz2tsdPWkqL85JCvzGMnlm9G3siAiF/zVfqXPd3Zbmw06wAU6Js3Yc6lu8ng0Yauu aWbHIPzicOHXw43gBscl7mtkkRRRVCbcqfu/R3pRpeKOA8W/l0TUkbTBzV81XDMIjkSt TvvmaMEncE5BdKquk8AiLjSw8uHcUJNUe4dANi5AAHzrO1FnQEFK0ibBHCUEyGid6GTN KiUlxx8FFainoGFGgyDSq3qN+BOTWuQcWVINkiBzKKg8o7Zq3XM7PaN6fuDV+hyWL7Dv 70aw== 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 x19si8463222pgc.261.2018.04.22.08.58.47; Sun, 22 Apr 2018 08:59:01 -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 S1754655AbeDVP5d (ORCPT + 99 others); Sun, 22 Apr 2018 11:57:33 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46856 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754000AbeDVN7Y (ORCPT ); Sun, 22 Apr 2018 09:59:24 -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 B5D35412; Sun, 22 Apr 2018 13:59:23 +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.16 112/196] ALSA: pcm: Fix endless loop for XRUN recovery in OSS emulation Date: Sun, 22 Apr 2018 15:52:12 +0200 Message-Id: <20180422135110.065203129@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180422135104.278511750@linuxfoundation.org> References: <20180422135104.278511750@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.16-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 @@ -1128,13 +1128,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,