linux.git/sound/core/seq, branch v6.1.2

ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event

2022-11-19T08:20:11+00:00

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed.

seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes
matching snd_seq_dump_func_t. Adjust this and remove the casts. There
are not resulting binary output differences.

This was found as a result of Clang's new -Wcast-function-type-strict
flag, which is more sensitive than the simpler -Wcast-function-type,
which only checks for type width mismatches.

Reported-by: kernel test robot 
Link: https://lore.kernel.org/lkml/202211041527.HD8TLSE1-lkp@intel.com
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: "Gustavo A. R. Silva" 
Cc: alsa-devel@alsa-project.org
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20221118232346.never.380-kees@kernel.org
Signed-off-by: Takashi Iwai

ALSA: seq: Fix data-race at module auto-loading

2022-08-24T05:59:06+00:00

It's been reported that there is a possible data-race accessing to the
global card_requested[] array at ALSA sequencer core, which is used
for determining whether to call request_module() for the card or not.
This data race itself is almost harmless, as it might end up with one
extra request_module() call for the already loaded module at most.
But it's still better to fix.

This patch addresses the possible data race of card_requested[] and
client_requested[] arrays by replacing them with bitmask.
It's an atomic operation and can work without locks.

Reported-by: Abhishek Shah 
Cc: 
Link: https://lore.kernel.org/r/CAEHB24_ay6YzARpA1zgCsE7=H9CSJJzux618E=Ka4h0YdKn=qA@mail.gmail.com
Link: https://lore.kernel.org/r/20220823072717.1706-2-tiwai@suse.de
Signed-off-by: Takashi Iwai

ALSA: seq: oss: Fix data-race for max_midi_devs access

2022-08-23T15:00:12+00:00

ALSA OSS sequencer refers to a global variable max_midi_devs at
creating a new port, storing it to its own field.  Meanwhile this
variable may be changed by other sequencer events at
snd_seq_oss_midi_check_exit_port() in parallel, which may cause a data
race.

OTOH, this data race itself is almost harmless, as the access to the
MIDI device is done via get_mdev() and it's protected with a refcount,
hence its presence is guaranteed.

Though, it's sill better to address the data-race from the code sanity
POV, and this patch adds the proper spinlock for the protection.

Reported-by: Abhishek Shah 
Cc: 
Link: https://lore.kernel.org/r/CAEHB2493pZRXs863w58QWnUTtv3HHfg85aYhLn5HJHCwxqtHQg@mail.gmail.com
Link: https://lore.kernel.org/r/20220823072717.1706-1-tiwai@suse.de
Signed-off-by: Takashi Iwai

ALSA: seq: replace ternary operator with max()

2022-05-17T06:49:42+00:00

Fix the following coccicheck warning:

sound/core/seq/seq_ports.c:142:12-14: WARNING opportunity for max()

Signed-off-by: Guo Zhengkui 
Link: https://lore.kernel.org/r/20220517062518.123292-1-guozhengkui@vivo.com
Signed-off-by: Takashi Iwai

ALSA: seq: oss: fix typo

2022-03-14T06:51:22+00:00

Fix typo in "announcement".

Reported-by: Joe Perches 
Signed-off-by: Julia Lawall 
Link: https://lore.kernel.org/r/20220313085635.102123-1-Julia.Lawall@inria.fr
Signed-off-by: Takashi Iwai

ALSA: seq: oss: use kzalloc

2022-03-13T08:09:37+00:00

Use kzalloc instead of kmalloc + memset.

The semantic patch that makes this change is:
(https://coccinelle.gitlabpages.inria.fr/website/)

//
@@
expression res, size, flag;
@@
- res = kmalloc(size, flag);
+ res = kzalloc(size, flag);
  ...
- memset(res, 0, size);
//

Signed-off-by: Julia Lawall 

Link: https://lore.kernel.org/r/20220312102705.71413-4-Julia.Lawall@inria.fr
Signed-off-by: Takashi Iwai

ALSA: seq: virmidi: Add a drain operation

2022-01-06T15:08:07+00:00

If a driver does not supply a drain operation for outputs, a default code
path will execute msleep(50). Especially for a virtual midi device
this severely limmits the throughput.

This implementation for the virtual midi driver simply flushes the output
workqueue.

Signed-off-by: Stefan Sauer 
Link: https://lore.kernel.org/r/20220106124145.17254-1-st_kost@gmx.de
Signed-off-by: Takashi Iwai

ALSA: seq: Set upper limit of processed events

2021-12-07T16:52:28+00:00

Currently ALSA sequencer core tries to process the queued events as
much as possible when they become dispatchable.  If applications try
to queue too massive events to be processed at the very same timing,
the sequencer core would still try to process such all events, either
in the interrupt context or via some notifier; in either away, it
might be a cause of RCU stall or such problems.

As a potential workaround for those problems, this patch adds the
upper limit of the amount of events to be processed.  The remaining
events are processed in the next batch, so they won't be lost.

For the time being, it's limited up to 1000 events per queue, which
should be high enough for any normal usages.

Reported-by: Zqiang 
Reported-by: syzbot+bb950e68b400ab4f65f8@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20211102033222.3849-1-qiang.zhang1211@gmail.com
Link: https://lore.kernel.org/r/20211207165146.2888-1-tiwai@suse.de
Signed-off-by: Takashi Iwai

Merge branch 'for-linus' into for-next

2021-08-09T05:53:22+00:00

ALSA: seq: Fix racy deletion of subscriber

2021-08-03T11:43:40+00:00

It turned out that the current implementation of the port subscription
is racy.  The subscription contains two linked lists, and we have to
add to or delete from both lists.  Since both connection and
disconnection procedures perform the same order for those two lists
(i.e. src list, then dest list), when a deletion happens during a
connection procedure, the src list may be deleted before the dest list
addition completes, and this may lead to a use-after-free or an Oops,
even though the access to both lists are protected via mutex.

The simple workaround for this race is to change the access order for
the disconnection, namely, dest list, then src list.  This assures
that the connection has been established when disconnecting, and also
the concurrent deletion can be avoided.

Reported-and-tested-by: folkert 
Cc: 
Link: https://lore.kernel.org/r/20210801182754.GP890690@belle.intranet.vanheusden.com
Link: https://lore.kernel.org/r/20210803114312.2536-1-tiwai@suse.de
Signed-off-by: Takashi Iwai