Received: by 10.192.165.148 with SMTP id m20csp2459817imm; Sun, 22 Apr 2018 07:29:59 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+S6uf8yJqr0oDKZe/38uOBsnODSGYMnAZCc1B7m1pYP2x3nKF6HbRcjGpTPmPB4jGmx6pu X-Received: by 2002:a17:902:595e:: with SMTP id e30-v6mr17462318plj.233.1524407399101; Sun, 22 Apr 2018 07:29:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524407399; cv=none; d=google.com; s=arc-20160816; b=Lc4hcnMMDbCzw4B2jCaS8hxsyyn6vnRb/8H6XvU0eD3V73BA49LtpdeVBcp7Ye86Zo 5fsokidYMXGBffyNp5mXYnXyahLnY2HvjzpX7tsCa5ur9THytbBtglL2t8WI7RUHdrmx 6Wy5wTckKJ+z33uRXN8DQ+jcttdEa7FwMO/pk8gQzMI23e+pQGSxGTbEWcHBr6CDfHPB K7EG6/LCJi970hVdDvlJIyvHV8nyTmXSiInoFYUZXCc6yzI3WK06h7PlX6zW1AmZX5sa CKTBdQoCqOMjlytZzQscONK3vLNpdbtjGSP3Uhy56aQCUcnFtCrBPoWEGhP7r6oe2gCl 8G2w== 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=r+4KuXhB8ATOeI51nctZYZj9gNym8V8OPMUQS+8jwCU=; b=PRQhK8CDMoErzLn0wtWOsa0hFRSYIO6GcLvbRecwt7xcjt66QZCEW3940sG2GkXTKd ZKS8AGE2HRhE57qqrpnTBCBwfbTcWDyWS4FGE8qCVWNRNzzC+K5C7RE7/VV/mXDX6AJ/ xHeN0eF089OXnJIFQKEr3D3rlKzScjg4kzbAtcKjEsdU9wRvSm1gns9K5HLLl0YFbCJY 0pJJai1VPjPZwgTaIexS43VwpnV3zOmXZtXG4q07yET9m+X5Bsc5AMyTNfPookO7j8GX T3IQF9VZ7dfeo4E2OdTb0U/D0j/A1/y253Z8vilCGrUvl9kLUUQH9vdlbGo6wd4QXLNj 1flQ== 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 u9si9550917pfa.293.2018.04.22.07.29.22; Sun, 22 Apr 2018 07:29:59 -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 S1757537AbeDVOVY (ORCPT + 99 others); Sun, 22 Apr 2018 10:21:24 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:60974 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932399AbeDVOVM (ORCPT ); Sun, 22 Apr 2018 10:21:12 -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 EEE3998C; Sun, 22 Apr 2018 14:21:11 +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 3.18 36/52] ALSA: pcm: Fix endless loop for XRUN recovery in OSS emulation Date: Sun, 22 Apr 2018 15:54:09 +0200 Message-Id: <20180422135317.083787173@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180422135315.254787616@linuxfoundation.org> References: <20180422135315.254787616@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 3.18-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,