kernel/linux.git/sound/core/seq/oss, branch linux-4.4.y

ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info()

2021-01-30T12:25:54+00:00

commit 217bfbb8b0bfa24619b11ab75c135fec99b99b20 upstream. snd_seq_oss_synth_make_info() didn't check the error code from snd_seq_oss_midi_make_info(), and this leads to the call of strlcpy() with the uninitialized string as the source, which may lead to the access over the limit. Add the proper error check for avoiding the failure. Reported-by: syzbot+e42504ff21cff05a595f@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20210115093428.15882-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: oss: Avoid mutex lock for a long-time ioctl

2020-10-29T08:03:04+00:00

[ Upstream commit 2759caad2600d503c3b0ed800e7e03d2cd7a4c05 ] Recently we applied a fix to cover the whole OSS sequencer ioctls with the mutex for dealing with the possible races. This works fine in general, but in theory, this may lead to unexpectedly long stall if an ioctl like SNDCTL_SEQ_SYNC is issued and an event with the far future timestamp was queued. For fixing such a potential stall, this patch changes the mutex lock applied conditionally excluding such an ioctl command. Also, change the mutex_lock() with the interruptible version for user to allow escaping from the big-hammer mutex. Fixes: 80982c7e834e ("ALSA: seq: oss: Serialize ioctls") Suggested-by: Pavel Machek Link: https://lore.kernel.org/r/20200922083856.28572-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ALSA: seq: oss: Serialize ioctls

2020-08-21T08:52:55+00:00

commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream. Some ioctls via OSS sequencer API may race and lead to UAF when the port create and delete are performed concurrently, as spotted by a couple of syzkaller cases. This patch is an attempt to address it by serializing the ioctls with the existing register_mutex. Basically OSS sequencer API is an obsoleted interface and was designed without much consideration of the concurrency. There are very few applications with it, and the concurrent performance isn't asked, hence this "big hammer" approach should be good enough. Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com Suggested-by: Hillf Danton Cc: Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: oss: Fix running status after receiving sysex

2020-04-02T17:02:29+00:00

commit 6c3171ef76a0bad892050f6959a7eac02fb16df7 upstream. This is a similar bug like the previous case for virmidi: the invalid running status is kept after receiving a sysex message. Again the fix is to clear the running status after handling the sysex. Cc: Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de Link: https://lore.kernel.org/r/20200316090506.23966-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: fix incorrect order of dest_client/dest_ports arguments

2019-07-10T07:56:43+00:00

commit c3ea60c231446663afd6ea1054da6b7f830855ca upstream. There are two occurrances of a call to snd_seq_oss_fill_addr where the dest_client and dest_port arguments are in the wrong order. Fix this by swapping them around. Addresses-Coverity: ("Arguments in wrong order") Signed-off-by: Colin Ian King Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: oss: Fix Spectre v1 vulnerability

2019-04-03T04:23:26+00:00

commit c709f14f0616482b67f9fbcb965e1493a03ff30b upstream. dev is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap) Fix this by sanitizing dev before using it to index dp->synths. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: oss: Hardening for potential Spectre v1

2018-05-02T14:53:41+00:00

commit 8d218dd8116695ecda7164f97631c069938aa22e upstream. As Smatch recently suggested, a few places in OSS sequencer codes may expand the array directly from the user-space value with speculation, namely there are a significant amount of references to either info->ch[] or dp->synths[] array: sound/core/seq/oss/seq_oss_event.c:315 note_on_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_event.c:362 note_off_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_synth.c:470 snd_seq_oss_synth_load_patch() warn: potential spectre issue 'dp->synths' (local cap) sound/core/seq/oss/seq_oss_event.c:293 note_on_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_event.c:353 note_off_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:506 snd_seq_oss_synth_sysex() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:580 snd_seq_oss_synth_ioctl() warn: potential spectre issue 'dp->synths' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. We may put array_index_nospec() at each place, but here we take a different approach: - For dp->synths[], change the helpers to retrieve seq_oss_synthinfo pointer directly instead of the array expansion at each place - For info->ch[], harden in a normal way, as there are only a couple of places As a result, the existing helper, snd_seq_oss_synth_is_valid() is replaced with snd_seq_oss_synth_info(). Also, we cover MIDI device where a similar array expansion is done, too, although it wasn't reported by Smatch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: oss: Fix unbalanced use lock for synth MIDI device

2018-05-02T14:53:41+00:00

commit f5e94b4c6ebdabe0f602d796e0430180927521a0 upstream. When get_synthdev() is called for a MIDI device, it returns the fixed midi_synth_dev without the use refcounting. OTOH, the caller is supposed to unreference unconditionally after the usage, so this would lead to unbalanced refcount. This patch corrects the behavior and keep up the refcount balance also for the MIDI synth device. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: Fix OSS sysex delivery in OSS emulation

2017-11-15T16:13:12+00:00

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 Reported-by: Mark Salyzyn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: seq: oss: Don't drain at closing a client

2016-03-09T23:34:54+00:00

commit 197b958c1e76a575d77038cc98b4bebc2134279f upstream. The OSS sequencer client tries to drain the pending events at releasing. Unfortunately, as spotted by syzkaller fuzzer, this may lead to an unkillable process state when the event has been queued at the far future. Since the process being released can't be signaled any longer, it remains and waits for the echo-back event in that far future. Back to history, the draining feature was implemented at the time we misinterpreted POSIX definition for blocking file operation. Actually, such a behavior is superfluous at release, and we should just release the device as is instead of keeping it up forever. This patch just removes the draining call that may block the release for too long time unexpectedly. BugLink: http://lkml.kernel.org/r/CACT4Y+Y4kD-aBGj37rf-xBw9bH3GMU6P+MYg4W1e-s-paVD2pg@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman