[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1519831218.86264421@decadent.org.uk>
Date: Wed, 28 Feb 2018 15:20:18 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org, "Takashi Iwai" <tiwai@...e.de>,
syzbot+993cb4cfcbbff3947c21@...kaller.appspotmail.com
Subject: [PATCH 3.16 181/254] ALSA: pcm: Abort properly at pending signal
in OSS read/write loops
3.16.55-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@...e.de>
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@...kaller.appspotmail.com
Signed-off-by: Takashi Iwai <tiwai@...e.de>
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
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;
Powered by blists - more mailing lists