linux-toradex.git/sound/core/seq/seq_clientmgr.c, branch v4.19

ALSA: seq: Use no intrruptible mutex_lock

2018-08-01T20:54:36+00:00

All usages of mutex in ALSA sequencer core would take too long, hence
we don't have to care about the user interruption that makes things
complicated.  Let's replace them with simpler mutex_lock().

Signed-off-by: Takashi Iwai

ALSA: seq: Fix leftovers at probe error path

2018-08-01T20:54:36+00:00

The sequencer core module doesn't call some destructors in the error
path of the init code, which may leave some resources.

This patch mainly fix these leaks by calling the destructors
appropriately at alsa_seq_init().  Also the patch brings a few
cleanups along with it, namely:

- Expand the old "if ((err = xxx) < 0)" coding style
- Get rid of empty seq_queue_init() and its caller
- Change snd_seq_info_done() to void

Last but not least, a couple of functions lose __exit annotation since
they are called also in alsa_seq_init().

No functional changes but minor code cleanups.

Signed-off-by: Takashi Iwai

ALSA: seq: Fix poll() error return

2018-07-26T06:23:26+00:00

The sanity checks in ALSA sequencer and OSS sequencer emulation codes
return falsely -ENXIO from poll callback.  They should be EPOLLERR
instead.

This was caught thanks to the recent change to the return value.

Cc: 
Signed-off-by: Takashi Iwai

ALSA: seq: Fix UBSAN warning at SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT ioctl

2018-06-25T09:18:04+00:00

The kernel may spew a WARNING with UBSAN undefined behavior at
handling ALSA sequencer ioctl SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT:

UBSAN: Undefined behaviour in sound/core/seq/seq_clientmgr.c:2007:14
signed integer overflow:
2147483647 + 1 cannot be represented in type 'int'
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x122/0x1c8 lib/dump_stack.c:113
 ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
 handle_overflow+0x1c2/0x21f lib/ubsan.c:190
  __ubsan_handle_add_overflow+0x2a/0x31 lib/ubsan.c:198
 snd_seq_ioctl_query_next_client+0x1ac/0x1d0 sound/core/seq/seq_clientmgr.c:2007
 snd_seq_ioctl+0x264/0x3d0 sound/core/seq/seq_clientmgr.c:2144
 ....

It happens only when INT_MAX is passed there, as we're incrementing it
unconditionally.  So the fix is trivial, check the value with
INT_MAX.  Although the bug itself is fairly harmless, it's better to
fix it so that fuzzers won't hit this again later.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200211
Signed-off-by: Takashi Iwai

ALSA: seq: Clear client entry before deleting else at closing

2018-03-10T16:30:01+00:00

When releasing a client, we need to clear the clienttab[] entry at
first, then call snd_seq_queue_client_leave().  Otherwise, the
in-flight cell in the queue might be picked up by the timer interrupt
via snd_seq_check_queue() before calling snd_seq_queue_client_leave(),
and it's delivered to another queue while the client is clearing
queues.  This may eventually result in an uncleared cell remaining in
a queue, and the later snd_seq_pool_delete() may need to wait for a
long time until the event gets really processed.

By moving the clienttab[] clearance at the beginning of release, any
event delivery of a cell belonging to this client will fail at a later
point, since snd_seq_client_ptr() returns NULL.  Thus the cell that
was picked up by the timer interrupt will be returned immediately
without further delivery, and the long stall of snd_seq_delete_pool()
can be avoided, too.

Cc: 
Signed-off-by: Takashi Iwai

ALSA: seq: Remove superfluous snd_seq_queue_client_leave_cells() call

2018-03-08T11:06:07+00:00

With the previous two fixes for the write / ioctl races:
  ALSA: seq: Don't allow resizing pool in use
  ALSA: seq: More protection for concurrent write and ioctl races
the cells aren't any longer in queues at the point calling
snd_seq_pool_done() in snd_seq_ioctl_set_client_pool().  Hence the
function call snd_seq_queue_client_leave_cells() can be dropped safely
from there.

Suggested-by: Nicolai Stange 
Signed-off-by: Takashi Iwai

ALSA: seq: More protection for concurrent write and ioctl races

2018-03-08T11:05:37+00:00

This patch is an attempt for further hardening against races between
the concurrent write and ioctls.  The previous fix d15d662e89fc
("ALSA: seq: Fix racy pool initializations") covered the race of the
pool initialization at writer and the pool resize ioctl by the
client->ioctl_mutex (CVE-2018-1000004).  However, basically this mutex
should be applied more widely to the whole write operation for
avoiding the unexpected pool operations by another thread.

The only change outside snd_seq_write() is the additional mutex
argument to helper functions, so that we can unlock / relock the given
mutex temporarily during schedule() call for blocking write.

Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations")
Reported-by: 范龙飞 
Reported-by: Nicolai Stange 
Reviewed-and-tested-by: Nicolai Stange 
Cc: 
Signed-off-by: Takashi Iwai

ALSA: seq: Don't allow resizing pool in use

2018-03-08T07:59:26+00:00

This is a fix for a (sort of) fallout in the recent commit
d15d662e89fc ("ALSA: seq: Fix racy pool initializations") for
CVE-2018-1000004.
As the pool resize deletes the existing cells, it may lead to a race
when another thread is writing concurrently, eventually resulting a
UAF.

A simple workaround is not to allow the pool resizing when the pool is
in use.  It's an invalid behavior in anyway.

Fixes: d15d662e89fc ("ALSA: seq: Fix racy pool initializations")
Reported-by: 范龙飞 
Reported-by: Nicolai Stange 
Cc: 
Signed-off-by: Takashi Iwai

ALSA: seq: Fix racy pool initializations

2018-02-14T09:39:08+00:00

ALSA sequencer core initializes the event pool on demand by invoking
snd_seq_pool_init() when the first write happens and the pool is
empty.  Meanwhile user can reset the pool size manually via ioctl
concurrently, and this may lead to UAF or out-of-bound accesses since
the function tries to vmalloc / vfree the buffer.

A simple fix is to just wrap the snd_seq_pool_init() call with the
recently introduced client->ioctl_mutex; as the calls for
snd_seq_pool_init() from other side are always protected with this
mutex, we can avoid the race.

Reported-by: 范龙飞 
Cc: 
Signed-off-by: Takashi Iwai

vfs: do bulk POLL* -> EPOLL* replacement

2018-02-11T22:34:03+00:00

This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.

Scripted-by: Al Viro 
Signed-off-by: Linus Torvalds