All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Dmitry Vyukov" <dvyukov@google.com>
Cc: <alsa-devel@alsa-project.org>, "Jaroslav Kysela" <perex@perex.cz>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Alexander Potapenko" <glider@google.com>,
	"Kostya Serebryany" <kcc@google.com>,
	"syzkaller" <syzkaller@googlegroups.com>,
	"Sasha Levin" <sasha.levin@oracle.com>
Subject: Re: sound: out-of-bounds write in snd_rawmidi_kernel_write1
Date: Wed, 03 Feb 2016 13:02:35 +0100	[thread overview]
Message-ID: <s5hlh72gfxg.wl-tiwai@suse.de> (raw)
In-Reply-To: <s5hsi1aggzw.wl-tiwai@suse.de>

On Wed, 03 Feb 2016 12:39:31 +0100,
Takashi Iwai wrote:
> 
> On Wed, 03 Feb 2016 10:41:14 +0100,
> Takashi Iwai wrote:
> > 
> > On Wed, 03 Feb 2016 10:35:14 +0100,
> > Takashi Iwai wrote:
> > > 
> > > On Wed, 03 Feb 2016 09:57:50 +0100,
> > > Dmitry Vyukov wrote:
> > > > 
> > > > Hello,
> > > > 
> > > > The following program triggers an out-of-bounds write in
> > > > snd_rawmidi_kernel_write1 (run in parallel loop). It seems to try to
> > > > copy -1 bytes (aka 4GB) from user space into kernel smashing all on
> > > > its way.
> > > 
> > > What card is /dev/midi3?  Please check /proc/asound/cards.
> > > Is it MTPAV?
> > 
> > In anyway the patch below should paper over it.  But it's still
> > strange that it gets a negative value there.  Could you put
> > 
> >    WARN_ON(count1 < 0)
> > 
> > before the newly added check?
> > 
> > I tried it locally with virmidi but it didn't appear, so far.  Maybe
> > my setup is too slow and has fewer CPUs than yours.
> 
> Scratch my previous patch, I could reproduce the issue on a faster
> machine in my office now :)  Will work on it.

This turned out to be a race in updates of runtime->appl_ptr & co.
We do temporary spin unlock and relock while copying the user-space
data, and then update these values.  Meanwhile these values are
referred as the position to copy, and the concurrent accesses may lead
to the negative value.

Below is a quick fix for that, just updating these before the
temporary unlock.

The patch also fixes the read size where it has more race problems...

It seems working on my machine.  Let me know if this works for you,
too.  Then I'll cook up the official patch.


thanks,

Takashi

---
diff --git a/sound/core/rawmidi.c b/sound/core/rawmidi.c
index 26ca02248885..795437b10082 100644
--- a/sound/core/rawmidi.c
+++ b/sound/core/rawmidi.c
@@ -942,31 +942,36 @@ static long snd_rawmidi_kernel_read1(struct snd_rawmidi_substream *substream,
 	unsigned long flags;
 	long result = 0, count1;
 	struct snd_rawmidi_runtime *runtime = substream->runtime;
+	unsigned long appl_ptr;
 
+	spin_lock_irqsave(&runtime->lock, flags);
 	while (count > 0 && runtime->avail) {
 		count1 = runtime->buffer_size - runtime->appl_ptr;
 		if (count1 > count)
 			count1 = count;
-		spin_lock_irqsave(&runtime->lock, flags);
 		if (count1 > (int)runtime->avail)
 			count1 = runtime->avail;
+
+		/* update runtime->appl_ptr before unlocking for userbuf */
+		appl_ptr = runtime->appl_ptr;
+		runtime->appl_ptr += count1;
+		runtime->appl_ptr %= runtime->buffer_size;
+		runtime->avail -= count1;
+
 		if (kernelbuf)
-			memcpy(kernelbuf + result, runtime->buffer + runtime->appl_ptr, count1);
+			memcpy(kernelbuf + result, runtime->buffer + appl_ptr, count1);
 		if (userbuf) {
 			spin_unlock_irqrestore(&runtime->lock, flags);
 			if (copy_to_user(userbuf + result,
-					 runtime->buffer + runtime->appl_ptr, count1)) {
+					 runtime->buffer + appl_ptr, count1)) {
 				return result > 0 ? result : -EFAULT;
 			}
 			spin_lock_irqsave(&runtime->lock, flags);
 		}
-		runtime->appl_ptr += count1;
-		runtime->appl_ptr %= runtime->buffer_size;
-		runtime->avail -= count1;
-		spin_unlock_irqrestore(&runtime->lock, flags);
 		result += count1;
 		count -= count1;
 	}
+	spin_unlock_irqrestore(&runtime->lock, flags);
 	return result;
 }
 
@@ -1223,6 +1228,7 @@ static long snd_rawmidi_kernel_write1(struct snd_rawmidi_substream *substream,
 	unsigned long flags;
 	long count1, result;
 	struct snd_rawmidi_runtime *runtime = substream->runtime;
+	unsigned long appl_ptr;
 
 	if (!kernelbuf && !userbuf)
 		return -EINVAL;
@@ -1243,12 +1249,19 @@ static long snd_rawmidi_kernel_write1(struct snd_rawmidi_substream *substream,
 			count1 = count;
 		if (count1 > (long)runtime->avail)
 			count1 = runtime->avail;
+
+		/* update runtime->appl_ptr before unlocking for userbuf */
+		appl_ptr = runtime->appl_ptr;
+		runtime->appl_ptr += count1;
+		runtime->appl_ptr %= runtime->buffer_size;
+		runtime->avail -= count1;
+
 		if (kernelbuf)
-			memcpy(runtime->buffer + runtime->appl_ptr,
+			memcpy(runtime->buffer + appl_ptr,
 			       kernelbuf + result, count1);
 		else if (userbuf) {
 			spin_unlock_irqrestore(&runtime->lock, flags);
-			if (copy_from_user(runtime->buffer + runtime->appl_ptr,
+			if (copy_from_user(runtime->buffer + appl_ptr,
 					   userbuf + result, count1)) {
 				spin_lock_irqsave(&runtime->lock, flags);
 				result = result > 0 ? result : -EFAULT;
@@ -1256,9 +1269,6 @@ static long snd_rawmidi_kernel_write1(struct snd_rawmidi_substream *substream,
 			}
 			spin_lock_irqsave(&runtime->lock, flags);
 		}
-		runtime->appl_ptr += count1;
-		runtime->appl_ptr %= runtime->buffer_size;
-		runtime->avail -= count1;
 		result += count1;
 		count -= count1;
 	}

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: alsa-devel@alsa-project.org, Jaroslav Kysela <perex@perex.cz>,
	LKML <linux-kernel@vger.kernel.org>,
	Alexander Potapenko <glider@google.com>,
	Kostya Serebryany <kcc@google.com>,
	syzkaller <syzkaller@googlegroups.com>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: sound: out-of-bounds write in snd_rawmidi_kernel_write1
Date: Wed, 03 Feb 2016 13:02:35 +0100	[thread overview]
Message-ID: <s5hlh72gfxg.wl-tiwai@suse.de> (raw)
In-Reply-To: <s5hsi1aggzw.wl-tiwai@suse.de>

On Wed, 03 Feb 2016 12:39:31 +0100,
Takashi Iwai wrote:
> 
> On Wed, 03 Feb 2016 10:41:14 +0100,
> Takashi Iwai wrote:
> > 
> > On Wed, 03 Feb 2016 10:35:14 +0100,
> > Takashi Iwai wrote:
> > > 
> > > On Wed, 03 Feb 2016 09:57:50 +0100,
> > > Dmitry Vyukov wrote:
> > > > 
> > > > Hello,
> > > > 
> > > > The following program triggers an out-of-bounds write in
> > > > snd_rawmidi_kernel_write1 (run in parallel loop). It seems to try to
> > > > copy -1 bytes (aka 4GB) from user space into kernel smashing all on
> > > > its way.
> > > 
> > > What card is /dev/midi3?  Please check /proc/asound/cards.
> > > Is it MTPAV?
> > 
> > In anyway the patch below should paper over it.  But it's still
> > strange that it gets a negative value there.  Could you put
> > 
> >    WARN_ON(count1 < 0)
> > 
> > before the newly added check?
> > 
> > I tried it locally with virmidi but it didn't appear, so far.  Maybe
> > my setup is too slow and has fewer CPUs than yours.
> 
> Scratch my previous patch, I could reproduce the issue on a faster
> machine in my office now :)  Will work on it.

This turned out to be a race in updates of runtime->appl_ptr & co.
We do temporary spin unlock and relock while copying the user-space
data, and then update these values.  Meanwhile these values are
referred as the position to copy, and the concurrent accesses may lead
to the negative value.

Below is a quick fix for that, just updating these before the
temporary unlock.

The patch also fixes the read size where it has more race problems...

It seems working on my machine.  Let me know if this works for you,
too.  Then I'll cook up the official patch.


thanks,

Takashi

---
diff --git a/sound/core/rawmidi.c b/sound/core/rawmidi.c
index 26ca02248885..795437b10082 100644
--- a/sound/core/rawmidi.c
+++ b/sound/core/rawmidi.c
@@ -942,31 +942,36 @@ static long snd_rawmidi_kernel_read1(struct snd_rawmidi_substream *substream,
 	unsigned long flags;
 	long result = 0, count1;
 	struct snd_rawmidi_runtime *runtime = substream->runtime;
+	unsigned long appl_ptr;
 
+	spin_lock_irqsave(&runtime->lock, flags);
 	while (count > 0 && runtime->avail) {
 		count1 = runtime->buffer_size - runtime->appl_ptr;
 		if (count1 > count)
 			count1 = count;
-		spin_lock_irqsave(&runtime->lock, flags);
 		if (count1 > (int)runtime->avail)
 			count1 = runtime->avail;
+
+		/* update runtime->appl_ptr before unlocking for userbuf */
+		appl_ptr = runtime->appl_ptr;
+		runtime->appl_ptr += count1;
+		runtime->appl_ptr %= runtime->buffer_size;
+		runtime->avail -= count1;
+
 		if (kernelbuf)
-			memcpy(kernelbuf + result, runtime->buffer + runtime->appl_ptr, count1);
+			memcpy(kernelbuf + result, runtime->buffer + appl_ptr, count1);
 		if (userbuf) {
 			spin_unlock_irqrestore(&runtime->lock, flags);
 			if (copy_to_user(userbuf + result,
-					 runtime->buffer + runtime->appl_ptr, count1)) {
+					 runtime->buffer + appl_ptr, count1)) {
 				return result > 0 ? result : -EFAULT;
 			}
 			spin_lock_irqsave(&runtime->lock, flags);
 		}
-		runtime->appl_ptr += count1;
-		runtime->appl_ptr %= runtime->buffer_size;
-		runtime->avail -= count1;
-		spin_unlock_irqrestore(&runtime->lock, flags);
 		result += count1;
 		count -= count1;
 	}
+	spin_unlock_irqrestore(&runtime->lock, flags);
 	return result;
 }
 
@@ -1223,6 +1228,7 @@ static long snd_rawmidi_kernel_write1(struct snd_rawmidi_substream *substream,
 	unsigned long flags;
 	long count1, result;
 	struct snd_rawmidi_runtime *runtime = substream->runtime;
+	unsigned long appl_ptr;
 
 	if (!kernelbuf && !userbuf)
 		return -EINVAL;
@@ -1243,12 +1249,19 @@ static long snd_rawmidi_kernel_write1(struct snd_rawmidi_substream *substream,
 			count1 = count;
 		if (count1 > (long)runtime->avail)
 			count1 = runtime->avail;
+
+		/* update runtime->appl_ptr before unlocking for userbuf */
+		appl_ptr = runtime->appl_ptr;
+		runtime->appl_ptr += count1;
+		runtime->appl_ptr %= runtime->buffer_size;
+		runtime->avail -= count1;
+
 		if (kernelbuf)
-			memcpy(runtime->buffer + runtime->appl_ptr,
+			memcpy(runtime->buffer + appl_ptr,
 			       kernelbuf + result, count1);
 		else if (userbuf) {
 			spin_unlock_irqrestore(&runtime->lock, flags);
-			if (copy_from_user(runtime->buffer + runtime->appl_ptr,
+			if (copy_from_user(runtime->buffer + appl_ptr,
 					   userbuf + result, count1)) {
 				spin_lock_irqsave(&runtime->lock, flags);
 				result = result > 0 ? result : -EFAULT;
@@ -1256,9 +1269,6 @@ static long snd_rawmidi_kernel_write1(struct snd_rawmidi_substream *substream,
 			}
 			spin_lock_irqsave(&runtime->lock, flags);
 		}
-		runtime->appl_ptr += count1;
-		runtime->appl_ptr %= runtime->buffer_size;
-		runtime->avail -= count1;
 		result += count1;
 		count -= count1;
 	}

  reply	other threads:[~2016-02-03 12:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03  8:57 sound: out-of-bounds write in snd_rawmidi_kernel_write1 Dmitry Vyukov
2016-02-03  8:57 ` Dmitry Vyukov
2016-02-03  9:35 ` Takashi Iwai
2016-02-03  9:35   ` Takashi Iwai
2016-02-03  9:41   ` Takashi Iwai
2016-02-03  9:41     ` Takashi Iwai
2016-02-03 11:39     ` Takashi Iwai
2016-02-03 11:39       ` Takashi Iwai
2016-02-03 12:02       ` Takashi Iwai [this message]
2016-02-03 12:02         ` Takashi Iwai
2016-02-03 13:37         ` Dmitry Vyukov
2016-02-03 14:26           ` Takashi Iwai
2016-02-03 13:25   ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hlh72gfxg.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kcc@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=sasha.levin@oracle.com \
    --cc=syzkaller@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.