Received: by 10.223.185.116 with SMTP id b49csp6402147wrg; Wed, 28 Feb 2018 08:49:46 -0800 (PST) X-Google-Smtp-Source: AH8x225xatd/LZrAIPDWtA4comxXCozHwyRMWUgmCgwFhP8u0ZqF94lB17DTVhSUbGisaNyBV5SG X-Received: by 10.101.81.4 with SMTP id f4mr15293232pgq.30.1519836586063; Wed, 28 Feb 2018 08:49:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519836586; cv=none; d=google.com; s=arc-20160816; b=LDtt25qnIKbwwIDDuYOaWet2kc0n2Lhfm8Id7g5eo77T0RHyPTzMG79KOUyNvMCwmk r/ehU+4f5O5TnRE1X0SNNKQvUCQyfnvf6HsVLFe7/FZbT7Wje7AYXvpGu4MGwr3IEnX1 p6uZIV9GMlPRL5c3r+iuGBl8Tyx3C0QCO+GhD1UltDBzSJjt1r+qJQHpHfVzHyY/iI54 2+mOrmPJQxPrGQ0GS8/9dyhakQbG6ZoJ2wIC5+FQAzdmQX68NpwlzbiPq1a/8bDNY1tb p9Q2Zk3E74psFmiMkbA+e6RAf+8+2efSA0a8W7b0vJsdUB8IkdBGTv3Bn/Kjez0TOG5S GNyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=pfWxPBxbAITE51oE8kMC/bw3VcZwBgpcAwGTqwsRxXA=; b=OqxaT9NFuJS5T6nOJtwYJ3NQWIJwAqAtEUhaSRM2Sk73oudGN+mrNAdrkluIOqx1ki MI3hlQogA0bni/L3U0p0e+rUJ0DxiN1W4dtChDLP+9E82LA3GI2t0nB/o6csw2CsDZab tTAcUN/lsZI9tIuUKezgO66tLMcYSmgvG8JtjIDCxl7GQKiLKL9g5lpYdpfZWhSSiTaF SUWqLQVVAO/Xtl/x5SPqDoIil6RxXnRwEqQKZhxFiWQweLkx6u1aqM2/tLuoEAhUyjMj MUz5EKkJaNCUoCMiZWq4eoQUCVb0LJJPps/RJVim993A/R2ayV2PiFUlYPAEn1H5DPWE UZEQ== 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 g11si1231067pgf.5.2018.02.28.08.49.30; Wed, 28 Feb 2018 08:49:46 -0800 (PST) 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 S1753343AbeB1Qs0 (ORCPT + 99 others); Wed, 28 Feb 2018 11:48:26 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34588 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934311AbeB1P6x (ORCPT ); Wed, 28 Feb 2018 10:58:53 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yk-0006XQ-9k; Wed, 28 Feb 2018 15:22:23 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yi-0000DO-TV; Wed, 28 Feb 2018 15:22:20 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Takashi Iwai" , syzbot+993cb4cfcbbff3947c21@syzkaller.appspotmail.com Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 181/254] ALSA: pcm: Abort properly at pending signal in OSS read/write loops In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai commit 29159a4ed7044c52e3e2cf1a9fb55cec4745c60b upstream. The loops for read and write in PCM OSS emulation have no proper check of pending signals, and they keep processing even after user tries to break. This results in a very long delay, often seen as RCU stall when a huge unprocessed bytes remain queued. The bug could be easily triggered by syzkaller. As a simple workaround, this patch adds the proper check of pending signals and aborts the loop appropriately. Reported-by: syzbot+993cb4cfcbbff3947c21@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings --- sound/core/oss/pcm_oss.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1417,6 +1417,10 @@ static ssize_t snd_pcm_oss_write1(struct tmp != runtime->oss.period_bytes) break; } + if (signal_pending(current)) { + tmp = -ERESTARTSYS; + goto err; + } } mutex_unlock(&runtime->oss.params_lock); return xfer; @@ -1502,6 +1506,10 @@ static ssize_t snd_pcm_oss_read1(struct bytes -= tmp; xfer += tmp; } + if (signal_pending(current)) { + tmp = -ERESTARTSYS; + goto err; + } } mutex_unlock(&runtime->oss.params_lock); return xfer;