Received: by 10.192.165.148 with SMTP id m20csp2464019imm; Sun, 22 Apr 2018 07:34:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx49LbmaXNq9vtwTYxdZDrvdIwvz66wMLNosXYytend5klsDLXtwuxYR92yjMPyOspFsnqXEZ X-Received: by 2002:a17:902:564:: with SMTP id 91-v6mr17430395plf.63.1524407692062; Sun, 22 Apr 2018 07:34:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524407692; cv=none; d=google.com; s=arc-20160816; b=llJYuayN/ztuifulwHoaU7qLeeBUshQuu+c+N3mjuxU1xIcbfaGL5XJa5TcqJ+g/9Q XqHgD75Yihdj54Z7A0MklWGzuImlgzCgmAi1KRJRleRdAuBmdCM748dvdS3FFw2ZioFl xxE6/3QOTQc0zMySpwrwdB5zE6sYZYPC8ADn64EekWO06g5EzAiZidU8TG4NprU7HUUP V6LAaHHHg5j32MMiLVTq7hcE69kqnLTKRFHdvSJXlWoLhvuLJSdhwadCdZhTqz3b7Uig BD4pAM+QVEcwD9qxqE7kJGfz8+DMLb/aONFx/AYndk8SEtQvNnOOzhcdyvw1aN3zLyqV vzCA== 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=OhTD0/Ug0W6QiUDFSfY0tJVKI6hLGBD7KxFcxKV6UEg=; b=E0FiMGdgVT5t4AVcXXrlJqNzZF0MZQtRATFgmT7kj6Jyb1PkjGDMtyRAtai82Cx7m3 IlTJ4kbhDal0c59A5OxOCch2mmz0yJHV7TXEFXPraqUQ/7e8FzyxksmWLmKWSHhC11zR mfnwumPQHreVSu5T5ILtvdxde8wHEUCHq62+/1O6ldSTb7XHBpAwpSsArUAJTfz2kE4q SWJKZefzKTdCx3D5CIydHrfIDG6Wf0VNeS2wlVHMwVhfpu9iMmMDc75iOHtlYMXJCbY3 AkdQQtvdRoMMQFOS+WniGPW+zVALfGDluVAlxRUrXFd6UZVAQOwRCfQIrrLfhBDvJ+tn ZlEA== 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 f28-v6si11095613plj.255.2018.04.22.07.34.15; Sun, 22 Apr 2018 07:34:52 -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 S1757345AbeDVOT6 (ORCPT + 99 others); Sun, 22 Apr 2018 10:19:58 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:60004 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757318AbeDVOTy (ORCPT ); Sun, 22 Apr 2018 10:19:54 -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 D0728360; Sun, 22 Apr 2018 14:19:53 +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.4 70/97] ALSA: pcm: Fix endless loop for XRUN recovery in OSS emulation Date: Sun, 22 Apr 2018 15:53:48 +0200 Message-Id: <20180422135309.086919953@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180422135304.577223025@linuxfoundation.org> References: <20180422135304.577223025@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.4-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 @@ -1138,13 +1138,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,