<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/sound/core/seq/seq_queue.h, branch v4.14.229</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: Use bool for snd_seq_queue internal flags</title>
<updated>2021-01-09T12:37:38+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2020-12-06T08:34:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c5eae3edc5273ac59dab70fd49114cce729f27f4'/>
<id>c5eae3edc5273ac59dab70fd49114cce729f27f4</id>
<content type='text'>
commit 4ebd47037027c4beae99680bff3b20fdee5d7c1e upstream.

The snd_seq_queue struct contains various flags in the bit fields.
Those are categorized to two different use cases, both of which are
protected by different spinlocks.  That implies that there are still
potential risks of the bad operations for bit fields by concurrent
accesses.

For addressing the problem, this patch rearranges those flags to be
a standard bool instead of a bit field.

Reported-by: syzbot+63cbe31877bb80ef58f5@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20201206083456.21110-1-tiwai@suse.de
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 4ebd47037027c4beae99680bff3b20fdee5d7c1e upstream.

The snd_seq_queue struct contains various flags in the bit fields.
Those are categorized to two different use cases, both of which are
protected by different spinlocks.  That implies that there are still
potential risks of the bad operations for bit fields by concurrent
accesses.

For addressing the problem, this patch rearranges those flags to be
a standard bool instead of a bit field.

Reported-by: syzbot+63cbe31877bb80ef58f5@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20201206083456.21110-1-tiwai@suse.de
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: 2nd attempt at fixing race creating a queue</title>
<updated>2017-08-15T06:02:35+00:00</updated>
<author>
<name>Daniel Mentz</name>
<email>danielmentz@google.com</email>
</author>
<published>2017-08-14T21:46:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=7e1d90f60a0d501c8503e636942ca704a454d910'/>
<id>7e1d90f60a0d501c8503e636942ca704a454d910</id>
<content type='text'>
commit 4842e98f26dd80be3623c4714a244ba52ea096a8 ("ALSA: seq: Fix race at
creating a queue") attempted to fix a race reported by syzkaller. That
fix has been described as follows:

"
When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
new queue element to the public list before referencing it.  Thus the
queue might be deleted before the call of snd_seq_queue_use(), and it
results in the use-after-free error, as spotted by syzkaller.

The fix is to reference the queue object at the right time.
"

Even with that fix in place, syzkaller reported a use-after-free error.
It specifically pointed to the last instruction "return q-&gt;queue" in
snd_seq_queue_alloc(). The pointer q is being used after kfree() has
been called on it.

It turned out that there is still a small window where a race can
happen. The window opens at
snd_seq_ioctl_create_queue()-&gt;snd_seq_queue_alloc()-&gt;queue_list_add()
and closes at
snd_seq_ioctl_create_queue()-&gt;queueptr()-&gt;snd_use_lock_use(). Between
these two calls, a different thread could delete the queue and possibly
re-create a different queue in the same location in queue_list.

This change prevents this situation by calling snd_use_lock_use() from
snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the
caller's responsibility to call snd_use_lock_free(&amp;q-&gt;use_lock).

Fixes: 4842e98f26dd ("ALSA: seq: Fix race at creating a queue")
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Daniel Mentz &lt;danielmentz@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4842e98f26dd80be3623c4714a244ba52ea096a8 ("ALSA: seq: Fix race at
creating a queue") attempted to fix a race reported by syzkaller. That
fix has been described as follows:

"
When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
new queue element to the public list before referencing it.  Thus the
queue might be deleted before the call of snd_seq_queue_use(), and it
results in the use-after-free error, as spotted by syzkaller.

The fix is to reference the queue object at the right time.
"

Even with that fix in place, syzkaller reported a use-after-free error.
It specifically pointed to the last instruction "return q-&gt;queue" in
snd_seq_queue_alloc(). The pointer q is being used after kfree() has
been called on it.

It turned out that there is still a small window where a race can
happen. The window opens at
snd_seq_ioctl_create_queue()-&gt;snd_seq_queue_alloc()-&gt;queue_list_add()
and closes at
snd_seq_ioctl_create_queue()-&gt;queueptr()-&gt;snd_use_lock_use(). Between
these two calls, a different thread could delete the queue and possibly
re-create a different queue in the same location in queue_list.

This change prevents this situation by calling snd_use_lock_use() from
snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the
caller's responsibility to call snd_use_lock_free(&amp;q-&gt;use_lock).

Fixes: 4842e98f26dd ("ALSA: seq: Fix race at creating a queue")
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Daniel Mentz &lt;danielmentz@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ALSA] semaphore -&gt; mutex (core part)</title>
<updated>2006-03-22T09:24:50+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@elte.hu</email>
</author>
<published>2006-01-16T15:29:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1a60d4c5a0c4028559585a74e48593b16e1ca9b2'/>
<id>1a60d4c5a0c4028559585a74e48593b16e1ca9b2</id>
<content type='text'>
Semaphore to mutex conversion.

The conversion was generated via scripts, and the result was validated
automatically via a script as well.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Semaphore to mutex conversion.

The conversion was generated via scripts, and the result was validated
automatically via a script as well.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ALSA] Remove xxx_t typedefs: Sequencer</title>
<updated>2006-01-03T11:17:52+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2005-11-17T13:04:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c7e0b5bf9fff1b726495081447c107a2333fb82c'/>
<id>c7e0b5bf9fff1b726495081447c107a2333fb82c</id>
<content type='text'>
Modules: ALSA sequencer

Remove xxx_t typedefs from the core sequencer codes.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Modules: ALSA sequencer

Remove xxx_t typedefs from the core sequencer codes.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[ALSA] sound/core/: possible cleanups</title>
<updated>2005-05-29T08:11:20+00:00</updated>
<author>
<name>Adrian Bunk</name>
<email>bunk@stusta.de</email>
</author>
<published>2005-05-18T16:02:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=123992f728785e05f385d23893bd5ec69871aeb4'/>
<id>123992f728785e05f385d23893bd5ec69871aeb4</id>
<content type='text'>
PCM Midlevel,ALSA Core,Timer Midlevel,ALSA sequencer,Virtual Midi
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions
- remove the following unneeded EXPORT_SYMBOL's

Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PCM Midlevel,ALSA Core,Timer Midlevel,ALSA sequencer,Virtual Midi
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions
- remove the following unneeded EXPORT_SYMBOL's

Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</pre>
</div>
</content>
</entry>
</feed>
