<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/sound, branch v3.18.81</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>ALSA: seq: Fix OSS sysex delivery in OSS emulation</title>
<updated>2017-11-15T09:04:13+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-11-07T15:05:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2a5c83f5bab19d5eead42fe829e676ad367c0060'/>
<id>2a5c83f5bab19d5eead42fe829e676ad367c0060</id>
<content type='text'>
commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream.

The SYSEX event delivery in OSS sequencer emulation assumed that the
event is encoded in the variable-length data with the straight
buffering.  This was the normal behavior in the past, but during the
development, the chained buffers were introduced for carrying more
data, while the OSS code was left intact.  As a result, when a SYSEX
event with the chained buffer data is passed to OSS sequencer port,
it may end up with the wrong memory access, as if it were having a too
large buffer.

This patch addresses the bug, by applying the buffer data expansion by
the generic snd_seq_dump_var_event() helper function.

Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Reported-by: Mark Salyzyn &lt;salyzyn@android.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream.

The SYSEX event delivery in OSS sequencer emulation assumed that the
event is encoded in the variable-length data with the straight
buffering.  This was the normal behavior in the past, but during the
development, the chained buffers were introduced for carrying more
data, while the OSS code was left intact.  As a result, when a SYSEX
event with the chained buffer data is passed to OSS sequencer port,
it may end up with the wrong memory access, as if it were having a too
large buffer.

This patch addresses the bug, by applying the buffer data expansion by
the generic snd_seq_dump_var_event() helper function.

Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Reported-by: Mark Salyzyn &lt;salyzyn@android.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: adau17x1: Workaround for noise bug in ADC</title>
<updated>2017-11-08T09:03:48+00:00</updated>
<author>
<name>Ricard Wanderlof</name>
<email>ricard.wanderlof@axis.com</email>
</author>
<published>2017-09-07T13:31:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=211b1914f59a95bcecefec72b952748b8166cadd'/>
<id>211b1914f59a95bcecefec72b952748b8166cadd</id>
<content type='text'>
commit 1e6f4fc06f6411adf98bbbe7fcd79442cd2b2a75 upstream.

The ADC in the ADAU1361 (and possibly other Analog Devices codecs)
exhibits a cyclic variation in the noise floor (in our test setup between
-87 and -93 dB), a new value being attained within this range whenever a
new capture stream is started. The cycle repeats after about 10 or 11
restarts.

The workaround recommended by the manufacturer is to toggle the ADOSR bit
in the Converter Control 0 register each time a new capture stream is
started.

I have verified that the patch fixes this problem on the ADAU1361, and
according to the manufacturer toggling the bit in question in this manner
will at least have no detrimental effect on other chips served by this
driver.

Signed-off-by: Ricard Wanderlof &lt;ricardw@axis.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1e6f4fc06f6411adf98bbbe7fcd79442cd2b2a75 upstream.

The ADC in the ADAU1361 (and possibly other Analog Devices codecs)
exhibits a cyclic variation in the noise floor (in our test setup between
-87 and -93 dB), a new value being attained within this range whenever a
new capture stream is started. The cycle repeats after about 10 or 11
restarts.

The workaround recommended by the manufacturer is to toggle the ADOSR bit
in the Converter Control 0 register each time a new capture stream is
started.

I have verified that the patch fixes this problem on the ADAU1361, and
according to the manufacturer toggling the bit in question in this manner
will at least have no detrimental effect on other chips served by this
driver.

Signed-off-by: Ricard Wanderlof &lt;ricardw@axis.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: seq: Fix nested rwsem annotation for lockdep splat</title>
<updated>2017-11-08T09:03:48+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-29T10:10:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e2943f47605b0e1be306f10887c1255007de54c4'/>
<id>e2943f47605b0e1be306f10887c1255007de54c4</id>
<content type='text'>
commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 upstream.

syzkaller reported the lockdep splat due to the possible deadlock of
grp-&gt;list_mutex of each sequencer client object.  Actually this is
rather a false-positive report due to the missing nested lock
annotations.  The sequencer client may deliver the event directly to
another client which takes another own lock.

For addressing this issue, this patch replaces the simple down_read()
with down_read_nested().  As a lock subclass, the already existing
"hop" can be re-used, which indicates the depth of the call.

Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot &lt;bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com&gt;
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 upstream.

syzkaller reported the lockdep splat due to the possible deadlock of
grp-&gt;list_mutex of each sequencer client object.  Actually this is
rather a false-positive report due to the missing nested lock
annotations.  The sequencer client may deliver the event directly to
another client which takes another own lock.

For addressing this issue, this patch replaces the simple down_read()
with down_read_nested().  As a lock subclass, the already existing
"hop" can be re-used, which indicates the depth of the call.

Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot &lt;bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com&gt;
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: Add missing mutex lock for compat ioctls</title>
<updated>2017-11-08T09:03:48+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-29T10:02:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=856849bd48eed8e216d3a31add70067144400bad'/>
<id>856849bd48eed8e216d3a31add70067144400bad</id>
<content type='text'>
commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 upstream.

The races among ioctl and other operations were protected by the
commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and
later fixes, but one code path was forgotten in the scenario: the
32bit compat ioctl.  As syzkaller recently spotted, a very similar
use-after-free may happen with the combination of compat ioctls.

The fix is simply to apply the same ioctl_lock to the compat_ioctl
callback, too.

Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls")
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot &lt;bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 upstream.

The races among ioctl and other operations were protected by the
commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and
later fixes, but one code path was forgotten in the scenario: the
32bit compat ioctl.  As syzkaller recently spotted, a very similar
use-after-free may happen with the combination of compat ioctls.

The fix is simply to apply the same ioctl_lock to the compat_ioctl
callback, too.

Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls")
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot &lt;bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda: Remove superfluous '-' added by printk conversion</title>
<updated>2017-10-27T08:17:23+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-17T09:58:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e2c0ddbe64bdeb7f68013305943192a5b95c2590'/>
<id>e2c0ddbe64bdeb7f68013305943192a5b95c2590</id>
<content type='text'>
commit 6bf88a343db2b3c160edf9b82a74966b31cc80bd upstream.

While converting the error messages to the standard macros in the
commit 4e76a8833fac ("ALSA: hda - Replace with standard printk"), a
superfluous '-' slipped in the code mistakenly.  Its influence is
almost negligible, merely shows a dB value as negative integer instead
of positive integer (or vice versa) in the rare error message.
So let's kill this embarrassing byte to show more correct value.

Fixes: 4e76a8833fac ("ALSA: hda - Replace with standard printk")
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6bf88a343db2b3c160edf9b82a74966b31cc80bd upstream.

While converting the error messages to the standard macros in the
commit 4e76a8833fac ("ALSA: hda - Replace with standard printk"), a
superfluous '-' slipped in the code mistakenly.  Its influence is
almost negligible, merely shows a dB value as negative integer instead
of positive integer (or vice versa) in the rare error message.
So let's kill this embarrassing byte to show more correct value.

Fixes: 4e76a8833fac ("ALSA: hda - Replace with standard printk")
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: seq: Enable 'use' locking in all configurations</title>
<updated>2017-10-27T08:17:23+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben.hutchings@codethink.co.uk</email>
</author>
<published>2017-10-17T23:45:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=38b463456f980caa60134dd118c51ce2f6897d1a'/>
<id>38b463456f980caa60134dd118c51ce2f6897d1a</id>
<content type='text'>
commit 8009d506a1dd00cf436b0c4cca0dcec130580a21 upstream.

The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
enabled.  This might once have been OK in non-preemptible
configurations, but even in that case snd_seq_read() may sleep while
relying on a 'use' lock.  So always use the proper implementations.

Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8009d506a1dd00cf436b0c4cca0dcec130580a21 upstream.

The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
enabled.  This might once have been OK in non-preemptible
configurations, but even in that case snd_seq_read() may sleep while
relying on a 'use' lock.  So always use the proper implementations.

Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: seq: Fix missing NULL check at remove_events ioctl</title>
<updated>2017-10-18T07:15:16+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2016-01-12T11:38:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=954e2ed41fec684048824230eb51bed0eae449ba'/>
<id>954e2ed41fec684048824230eb51bed0eae449ba</id>
<content type='text'>
commit 030e2c78d3a91dd0d27fef37e91950dde333eba1 upstream.

snd_seq_ioctl_remove_events() calls snd_seq_fifo_clear()
unconditionally even if there is no FIFO assigned, and this leads to
an Oops due to NULL dereference.  The fix is just to add a proper NULL
check.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Mark Salyzyn &lt;salyzyn@google.com&gt;
Cc: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 030e2c78d3a91dd0d27fef37e91950dde333eba1 upstream.

snd_seq_ioctl_remove_events() calls snd_seq_fifo_clear()
unconditionally even if there is no FIFO assigned, and this leads to
an Oops due to NULL dereference.  The fix is just to add a proper NULL
check.

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Mark Salyzyn &lt;salyzyn@google.com&gt;
Cc: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: caiaq: Fix stray URB at probe error path</title>
<updated>2017-10-18T07:15:16+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-11T14:39:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c57f813cb8807f07eab5f3048aa3445386c78387'/>
<id>c57f813cb8807f07eab5f3048aa3445386c78387</id>
<content type='text'>
commit 99fee508245825765ff60155fed43f970ff83a8f upstream.

caiaq driver doesn't kill the URB properly at its error path during
the probe, which may lead to a use-after-free error later.  This patch
addresses it.

Reported-by: Johan Hovold &lt;johan@kernel.org&gt;
Reviewed-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 99fee508245825765ff60155fed43f970ff83a8f upstream.

caiaq driver doesn't kill the URB properly at its error path during
the probe, which may lead to a use-after-free error later.  This patch
addresses it.

Reported-by: Johan Hovold &lt;johan@kernel.org&gt;
Reviewed-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: seq: Fix copy_from_user() call inside lock</title>
<updated>2017-10-18T07:15:16+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-09T08:02:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f12baf790258076b7f1f5b12e809124eafb730b0'/>
<id>f12baf790258076b7f1f5b12e809124eafb730b0</id>
<content type='text'>
commit 5803b023881857db32ffefa0d269c90280a67ee0 upstream.

The event handler in the virmidi sequencer code takes a read-lock for
the linked list traverse, while it's calling snd_seq_dump_var_event()
in the loop.  The latter function may expand the user-space data
depending on the event type.  It eventually invokes copy_from_user(),
which might be a potential dead-lock.

The sequencer core guarantees that the user-space data is passed only
with atomic=0 argument, but snd_virmidi_dev_receive_event() ignores it
and always takes read-lock().  For avoiding the problem above, this
patch introduces rwsem for non-atomic case, while keeping rwlock for
atomic case.

Also while we're at it: the superfluous irq flags is dropped in
snd_virmidi_input_open().

Reported-by: Jia-Ju Bai &lt;baijiaju1990@163.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5803b023881857db32ffefa0d269c90280a67ee0 upstream.

The event handler in the virmidi sequencer code takes a read-lock for
the linked list traverse, while it's calling snd_seq_dump_var_event()
in the loop.  The latter function may expand the user-space data
depending on the event type.  It eventually invokes copy_from_user(),
which might be a potential dead-lock.

The sequencer core guarantees that the user-space data is passed only
with atomic=0 argument, but snd_virmidi_dev_receive_event() ignores it
and always takes read-lock().  For avoiding the problem above, this
patch introduces rwsem for non-atomic case, while keeping rwlock for
atomic case.

Also while we're at it: the superfluous irq flags is dropped in
snd_virmidi_input_open().

Reported-by: Jia-Ju Bai &lt;baijiaju1990@163.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: seq: Fix use-after-free at creating a port</title>
<updated>2017-10-18T07:15:16+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-10-09T09:09:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=035e6d0b5b192ff5e168ed322304d29db108d790'/>
<id>035e6d0b5b192ff5e168ed322304d29db108d790</id>
<content type='text'>
commit 71105998845fb012937332fe2e806d443c09e026 upstream.

There is a potential race window opened at creating and deleting a
port via ioctl, as spotted by fuzzing.  snd_seq_create_port() creates
a port object and returns its pointer, but it doesn't take the
refcount, thus it can be deleted immediately by another thread.
Meanwhile, snd_seq_ioctl_create_port() still calls the function
snd_seq_system_client_ev_port_start() with the created port object
that is being deleted, and this triggers use-after-free like:

 BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1
 =============================================================================
 BUG kmalloc-512 (Tainted: G    B          ): kasan: bad access detected
 -----------------------------------------------------------------------------
 INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511
 	___slab_alloc+0x425/0x460
 	__slab_alloc+0x20/0x40
  	kmem_cache_alloc_trace+0x150/0x190
	snd_seq_create_port+0x94/0x9b0 [snd_seq]
	snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq]
 	snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
 	snd_seq_ioctl+0x40/0x80 [snd_seq]
 	do_vfs_ioctl+0x54b/0xda0
 	SyS_ioctl+0x79/0x90
 	entry_SYSCALL_64_fastpath+0x16/0x75
 INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717
 	__slab_free+0x204/0x310
 	kfree+0x15f/0x180
 	port_delete+0x136/0x1a0 [snd_seq]
 	snd_seq_delete_port+0x235/0x350 [snd_seq]
 	snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq]
 	snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
 	snd_seq_ioctl+0x40/0x80 [snd_seq]
 	do_vfs_ioctl+0x54b/0xda0
 	SyS_ioctl+0x79/0x90
 	entry_SYSCALL_64_fastpath+0x16/0x75
 Call Trace:
  [&lt;ffffffff81b03781&gt;] dump_stack+0x63/0x82
  [&lt;ffffffff81531b3b&gt;] print_trailer+0xfb/0x160
  [&lt;ffffffff81536db4&gt;] object_err+0x34/0x40
  [&lt;ffffffff815392d3&gt;] kasan_report.part.2+0x223/0x520
  [&lt;ffffffffa07aadf4&gt;] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
  [&lt;ffffffff815395fe&gt;] __asan_report_load1_noabort+0x2e/0x30
  [&lt;ffffffffa07aadf4&gt;] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
  [&lt;ffffffffa07aa8f0&gt;] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq]
  [&lt;ffffffff8136be50&gt;] ? taskstats_exit+0xbc0/0xbc0
  [&lt;ffffffffa07abc5c&gt;] snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
  [&lt;ffffffffa07abd10&gt;] snd_seq_ioctl+0x40/0x80 [snd_seq]
  [&lt;ffffffff8136d433&gt;] ? acct_account_cputime+0x63/0x80
  [&lt;ffffffff815b515b&gt;] do_vfs_ioctl+0x54b/0xda0
  .....

We may fix this in a few different ways, and in this patch, it's fixed
simply by taking the refcount properly at snd_seq_create_port() and
letting the caller unref the object after use.  Also, there is another
potential use-after-free by sprintf() call in snd_seq_create_port(),
and this is moved inside the lock.

This fix covers CVE-2017-15265.

Reported-and-tested-by: Michael23 Yu &lt;ycqzsy@gmail.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 71105998845fb012937332fe2e806d443c09e026 upstream.

There is a potential race window opened at creating and deleting a
port via ioctl, as spotted by fuzzing.  snd_seq_create_port() creates
a port object and returns its pointer, but it doesn't take the
refcount, thus it can be deleted immediately by another thread.
Meanwhile, snd_seq_ioctl_create_port() still calls the function
snd_seq_system_client_ev_port_start() with the created port object
that is being deleted, and this triggers use-after-free like:

 BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1
 =============================================================================
 BUG kmalloc-512 (Tainted: G    B          ): kasan: bad access detected
 -----------------------------------------------------------------------------
 INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511
 	___slab_alloc+0x425/0x460
 	__slab_alloc+0x20/0x40
  	kmem_cache_alloc_trace+0x150/0x190
	snd_seq_create_port+0x94/0x9b0 [snd_seq]
	snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq]
 	snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
 	snd_seq_ioctl+0x40/0x80 [snd_seq]
 	do_vfs_ioctl+0x54b/0xda0
 	SyS_ioctl+0x79/0x90
 	entry_SYSCALL_64_fastpath+0x16/0x75
 INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717
 	__slab_free+0x204/0x310
 	kfree+0x15f/0x180
 	port_delete+0x136/0x1a0 [snd_seq]
 	snd_seq_delete_port+0x235/0x350 [snd_seq]
 	snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq]
 	snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
 	snd_seq_ioctl+0x40/0x80 [snd_seq]
 	do_vfs_ioctl+0x54b/0xda0
 	SyS_ioctl+0x79/0x90
 	entry_SYSCALL_64_fastpath+0x16/0x75
 Call Trace:
  [&lt;ffffffff81b03781&gt;] dump_stack+0x63/0x82
  [&lt;ffffffff81531b3b&gt;] print_trailer+0xfb/0x160
  [&lt;ffffffff81536db4&gt;] object_err+0x34/0x40
  [&lt;ffffffff815392d3&gt;] kasan_report.part.2+0x223/0x520
  [&lt;ffffffffa07aadf4&gt;] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
  [&lt;ffffffff815395fe&gt;] __asan_report_load1_noabort+0x2e/0x30
  [&lt;ffffffffa07aadf4&gt;] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
  [&lt;ffffffffa07aa8f0&gt;] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq]
  [&lt;ffffffff8136be50&gt;] ? taskstats_exit+0xbc0/0xbc0
  [&lt;ffffffffa07abc5c&gt;] snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
  [&lt;ffffffffa07abd10&gt;] snd_seq_ioctl+0x40/0x80 [snd_seq]
  [&lt;ffffffff8136d433&gt;] ? acct_account_cputime+0x63/0x80
  [&lt;ffffffff815b515b&gt;] do_vfs_ioctl+0x54b/0xda0
  .....

We may fix this in a few different ways, and in this patch, it's fixed
simply by taking the refcount properly at snd_seq_create_port() and
letting the caller unref the object after use.  Also, there is another
potential use-after-free by sprintf() call in snd_seq_create_port(),
and this is moved inside the lock.

This fix covers CVE-2017-15265.

Reported-and-tested-by: Michael23 Yu &lt;ycqzsy@gmail.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
