10 Sep, 2020
1 commit
-
commit 949a1ebe8cea7b342085cb6a4946b498306b9493 upstream.
The PCM OSS mulaw plugin has a check of the format of the counter part
whether it's a linear format. The check is with snd_BUG_ON() that
emits WARN_ON() when the debug config is set, and it confuses
syzkaller as if it were a serious issue. Let's drop snd_BUG_ON() for
avoiding that.While we're at it, correct the error code to a more suitable, EINVAL.
Reported-by: syzbot+23b22dc2e0b81cbfcc95@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20200901131802.18157-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
11 Aug, 2020
1 commit
-
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
29 Jul, 2020
1 commit
-
commit 60379ba08532eca861e933b389526a4dc89e0c42 upstream.
snd_info_get_line() has a sanity check of NULL buffer -- both buffer
itself being NULL and buffer->buffer being NULL. Basically both
checks are valid and necessary, but the problem is that it's with
snd_BUG_ON() macro that triggers WARN_ON(). The latter condition
(NULL buffer->buffer) can be met arbitrarily by user since the buffer
is allocated at the first write, so it means that user can trigger
WARN_ON() at will.This patch addresses it by simply moving buffer->buffer NULL check out
of snd_BUG_ON() so that spurious WARNING is no longer triggered.Reported-by: syzbot+e42d0746c3c3699b6061@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20200717084023.5928-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
16 Jul, 2020
1 commit
-
[ Upstream commit f79a732a8325dfbd570d87f1435019d7e5501c6d ]
On partial_drain completion we should be in SNDRV_PCM_STATE_RUNNING
state, so set that for partially draining streams in
snd_compr_drain_notify() and use a flag for partially draining streamsWhile at it, add locks for stream state change in
snd_compr_drain_notify() as well.Fixes: f44f2a5417b2 ("ALSA: compress: fix drain calls blocking other compress functions (v6)")
Reviewed-by: Srinivas Kandagatla
Tested-by: Srinivas Kandagatla
Reviewed-by: Charles Keepax
Tested-by: Charles Keepax
Signed-off-by: Vinod Koul
Link: https://lore.kernel.org/r/20200629134737.105993-4-vkoul@kernel.org
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
17 Jun, 2020
2 commits
-
commit e18035cf5cb3d2bf8e4f4d350a23608bd208b934 upstream.
Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink
implementation. The code is fine, but generates a lockdep complaint:============================================
WARNING: possible recursive locking detected
5.7.1mq+ #381 Tainted: G O
--------------------------------------------
pulseaudio/4180 is trying to acquire lock:
ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm]but task is already holding lock:
ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]other info that might help us debug this:
Possible unsafe locking scenario:CPU0
----
lock(&group->lock);
lock(&group->lock);*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by pulseaudio/4180:
#0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm]
#1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]Cc: stable@vger.kernel.org
Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław
Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-HartmanSigned-off-by: Takashi Iwai
-
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.Cc: stable@vger.kernel.org
Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
Signed-off-by: Michał Mirosław
Link: https://lore.kernel.org/r/89c4a2487609a0ed6af3ecf01cc972bdc59a7a2d.1591634956.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
03 Jun, 2020
1 commit
-
[ Upstream commit fb8cd6481ffd126f35e9e146a0dcf0c4e8899f2e ]
The "info.index" variable can be 31 in "1 << info.index".
This might trigger an undefined behavior since 1 is signed.Fix this by casting 1 to 1u just to be sure "1u << 31" is defined.
Signed-off-by: Changming Liu
Cc:
Link: https://lore.kernel.org/r/BL0PR06MB4548170B842CB055C9AF695DE5B00@BL0PR06MB4548.namprd06.prod.outlook.com
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
27 May, 2020
1 commit
-
commit e7513c5786f8b33f0c107b3759e433bc6cbb2efa upstream.
There is a corner case that ALSA keeps increasing the hw_ptr but DMA
already stop working/updating the position for a long time.In following log we can see the position returned from DMA driver does
not move at all but the hw_ptr got increased at some point of time so
snd_pcm_avail() will return a large number which seems to be a buffer
underrun event from user space program point of view. The program
thinks there is space in the buffer and fill more data.[ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
...
[ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
[ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
[ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368This is because the hw_base will be increased by runtime->buffer_size
frames unconditionally if the hw_ptr is not updated for over half of
buffer time. As the hw_base increases, so does the hw_ptr increased
by the same number.The avail value returned from snd_pcm_avail() could exceed the limit
(buffer_size) easily becase the hw_ptr itself got increased by same
buffer_size samples when the corner case happens. In following log,
the buffer_size is 16368 samples but the avail is 21810 samples so
CRAS server complains about it.[ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
[ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810cras_server[1907]: pcm_avail returned frames larger than buf_size:
sof-glkda7219max: :0,5: 21810 > 16368By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
the hw_base will keep the same when buffer stall happens at long as
the interval between each HWSYNC call is shorter than half of buffer
time.Following is a log captured by a patched kernel. The hw_base/hw_ptr
value is fixed in this corner case and user space program should be
aware of the buffer stall and handle it.[ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
[ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
[ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
[ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
...
[ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0Signed-off-by: Brent Lu
Reviewed-by: Jaroslav Kysela
Cc:
Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
20 May, 2020
1 commit
-
commit c1f6e3c818dd734c30f6a7eeebf232ba2cf3181d upstream.
The rawmidi core allows user to resize the runtime buffer via ioctl,
and this may lead to UAF when performed during concurrent reads or
writes: the read/write functions unlock the runtime lock temporarily
during copying form/to user-space, and that's the race window.This patch fixes the hole by introducing a reference counter for the
runtime buffer read/write access and returns -EBUSY error when the
resize is performed concurrently against read/write.Note that the ref count field is a simple integer instead of
refcount_t here, since the all contexts accessing the buffer is
basically protected with a spinlock, hence we need no expensive atomic
ops. Also, note that this busy check is needed only against read /
write functions, and not in receive/transmit callbacks; the race can
happen only at the spinlock hole mentioned in the above, while the
whole function is protected for receive / transmit callbacks.Reported-by: butt3rflyh4ck
Cc:
Link: https://lore.kernel.org/r/CAFcO6XMWpUVK_yzzCpp8_XP7+=oUpQvuBeCbMffEDkpe8jWrfg@mail.gmail.com
Link: https://lore.kernel.org/r/s5heerw3r5z.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
06 May, 2020
1 commit
-
commit 4285de0725b1bf73608abbcd35ad7fd3ddc0b61e upstream.
The checks of the plugin buffer overflow in the previous fix by commit
f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved. Fix in the right
places.Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Cc:
Link: https://lore.kernel.org/r/20200424193350.19678-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
17 Apr, 2020
1 commit
-
commit ae769d3556644888c964635179ef192995f40793 upstream.
The recent fix for the OOB access in PCM OSS plugins (commit
f2ecf903ef06: "ALSA: pcm: oss: Avoid plugin buffer overflow") caused a
regression on OSS applications. The patch introduced the size check
in client and slave size calculations to limit to each plugin's buffer
size, but I overlooked that some code paths call those without
allocating the buffer but just for estimation.This patch fixes the bug by skipping the size check for those code
paths while keeping checking in the actual transfer calls.Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Tested-and-reported-by: Jari Ruusu
Cc:
Link: https://lore.kernel.org/r/20200403072515.25539-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
25 Mar, 2020
4 commits
-
commit 5461e0530c222129dfc941058be114b5cbc00837 upstream.
The return value checks in snd_pcm_plug_alloc() are covered with
snd_BUG_ON() macro that may trigger a kernel WARNING depending on the
kconfig. But since the error condition can be triggered by a weird
user space parameter passed to OSS layer, we shouldn't give the kernel
stack trace just for that. As it's a normal error condition, let's
remove snd_BUG_ON() macro usage there.Reported-by: syzbot+2a59ee7a9831b264f45e@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit f2ecf903ef06eb1bbbfa969db9889643d487e73a upstream.
Each OSS PCM plugins allocate its internal buffer per pre-calculation
of the max buffer size through the chain of plugins (calling
src_frames and dst_frames callbacks). This works for most plugins,
but the rate plugin might behave incorrectly. The calculation in the
rate plugin involves with the fractional position, i.e. it may vary
depending on the input position. Since the buffer size
pre-calculation is always done with the offset zero, it may return a
shorter size than it might be; this may result in the out-of-bound
access as spotted by fuzzer.This patch addresses those possible buffer overflow accesses by simply
setting the upper limit per the given buffer size for each plugin
before src_frames() and after dst_frames() calls.Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com
Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
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 -
commit 4384f167ce5fa7241b61bb0984d651bc528ddebe upstream.
The virmidi driver handles sysex event exceptionally in a short-cut
snd_seq_dump_var_event() call, but this missed the reset of the
running status. As a result, it may lead to an incomplete command
right after the sysex when an event with the same running status was
queued.Fix it by clearing the running status properly via alling
snd_midi_event_reset_decode() for that code path.Reported-by: Andreas Steinmetz
Cc:
Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
Link: https://lore.kernel.org/r/20200316090506.23966-2-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
29 Feb, 2020
2 commits
-
commit dc7497795e014d84699c3b8809ed6df35352dd74 upstream.
snd_seq_check_queue() passes the current tick and time of the given
queue as a pointer to snd_seq_prioq_cell_out(), but those might be
updated concurrently by the seq timer update.Fix it by retrieving the current tick and time via the proper helper
functions at first, and pass those values to snd_seq_prioq_cell_out()
later in the loops.snd_seq_timer_get_cur_time() takes a new argument and adjusts with the
current system time only when it's requested so; this update isn't
needed for snd_seq_check_queue(), as it's called either from the
interrupt handler or right after queuing.Also, snd_seq_timer_get_cur_tick() is changed to read the value in the
spinlock for the concurrency, too.Reported-by: syzbot+fd5e0eaa1a32999173b2@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-3-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit bb51e669fa49feb5904f452b2991b240ef31bc97 upstream.
The queue flags are represented in bit fields and the concurrent
access may result in unexpected results. Although the current code
should be mostly OK as it's only reading a field while writing other
fields as KCSAN reported, it's safer to cover both with a proper
spinlock protection.This patch fixes the possible concurrent read by protecting with
q->owner_lock. Also the queue owner field is protected as well since
it's the field to be protected by the lock itself.Reported-by: syzbot+65c6c92d04304d0a8efc@syzkaller.appspotmail.com
Reported-by: syzbot+e60ddfa48717579799dd@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-2-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2020
1 commit
-
[ Upstream commit d61fe22c2ae42d9fd76c34ef4224064cca4b04b0 ]
A design of ALSA control core allows applications to execute three
operations for TLV feature; read, write and command. Furthermore, it
allows driver developers to process the operations by two ways; allocated
array or callback function. In the former, read operation is just allowed,
thus developers uses the latter when device driver supports variety of
models or the target model is expected to dynamically change information
stored in TLV container.The core also allows applications to lock any element so that the other
applications can't perform write operation to the element for element
value and TLV information. When the element is locked, write and command
operation for TLV information are prohibited as well as element value.
Any read operation should be allowed in the case.At present, when an element has callback function for TLV information,
TLV read operation returns EPERM if the element is locked. On the
other hand, the read operation is success when an element has allocated
array for TLV information. In both cases, read operation is success for
element value expectedly.This commit fixes the bug. This change can be backported to v4.14
kernel or later.Signed-off-by: Takashi Sakamoto
Reviewed-by: Jaroslav Kysela
Link: https://lore.kernel.org/r/20191223093347.15279-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
23 Jan, 2020
1 commit
-
commit 60adcfde92fa40fcb2dbf7cc52f9b096e0cd109a upstream.
snd_seq_info_timer_read() reads the information of the timer assigned
for each queue, but it's done in a racy way which may lead to UAF as
spotted by syzkaller.This patch applies the missing q->timer_mutex lock while accessing the
timer object as well as a slight code change to adapt the standard
coding style.Reported-by: syzbot+2b2ef983f973e5c40943@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20200115203733.26530-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
09 Jan, 2020
1 commit
-
commit 2406ff9b86aa1b77fe1a6d15f37195ac1fdb2a14 upstream.
For non-x86 architectures, SNDRV_DMA_TYPE_DEV_UC should be treated
equivalent with SNDRV_DMA_TYPE_DEV, where the default mmap handler
still checks only about SNDRV_DMA_TYPE_DEV. Make the check more
proper.Note that all existing users of *_UC buffer types are x86-only, so
this doesn't fix any bug, but just for consistency.Fixes: 42e748a0b325 ("ALSA: memalloc: Add non-cached buffer type")
Link: https://lore.kernel.org/r/20191108165626.5947-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
31 Dec, 2019
3 commits
-
[ Upstream commit fdea53fe5de532969a332d6e5e727f2ad8bf084d ]
The fuzzer tries to open the timer instances as much as possible, and
this may cause a system hiccup easily. We've already introduced the
cap for the max number of available instances for the h/w timers, and
we should put such a limit also to the slave timers, too.This patch introduces the limit to the multiple opened slave timers.
The upper limit is hard-coded to 1000 for now, which should suffice
for any practical usages up to now.Link: https://lore.kernel.org/r/20191106154257.5853-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin -
[ Upstream commit 6111fd2370eecae9f11bfdc08ba097e0b51fcfd3 ]
The check for the mmap support via hw_support_mmap() function misses
the case where the device is with SNDRV_DMA_TYPE_DEV_UC, which should
have been treated equally as SNDRV_DMA_TYPE_DEV. Let's fix it.Note that this bug doesn't hit any practical problem, because
SNDRV_DMA_TYPE_DEV_UC is used only for x86-specific drivers
(snd-hda-intel and snd-intel8x0) for the specific platforms that need
the non-cached buffers. And, on such platforms, hw_support_mmap()
already returns true in anyway. That's the reason I didn't put
Cc-to-stable mark here. This is only for any theoretical future
extension.Fixes: 425da159707b ("ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*")
Fixes: 42e748a0b325 ("ALSA: memalloc: Add non-cached buffer type")
Link: https://lore.kernel.org/r/20191104101115.27311-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin -
commit add9d56d7b3781532208afbff5509d7382fb6efe upstream.
The current PCM code doesn't initialize explicitly the buffers
allocated for PCM streams, hence it might leak some uninitialized
kernel data or previous stream contents by mmapping or reading the
buffer before actually starting the stream.Since this is a common problem, this patch simply adds the clearance
of the buffer data at hw_params callback. Although this does only
zero-clear no matter which format is used, which doesn't mean the
silence for some formats, but it should be OK because the intention is
just to clear the previous data on the buffer.Reported-by: Lionel Koenig
Cc:
Link: https://lore.kernel.org/r/20191211155742.3213-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
13 Dec, 2019
1 commit
-
commit 4cc8d6505ab82db3357613d36e6c58a297f57f7c upstream.
syzkaller reported an invalid access in PCM OSS read, and this seems
to be an overflow of the internal buffer allocated for a plugin.
Since the rate plugin adjusts its transfer size dynamically, the
calculation for the chained plugin might be bigger than the given
buffer size in some extreme cases, which lead to such an buffer
overflow as caught by KASAN.Fix it by limiting the max transfer size properly by checking against
the destination size in each plugin transfer callback.Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
13 Nov, 2019
1 commit
-
If the nullity check for `substream->runtime` is outside of the lock
region, it is possible to have a null runtime in the critical section
if snd_pcm_detach_substream is called right before the lock.Signed-off-by: paulhsia
Link: https://lore.kernel.org/r/20191112171715.128727-2-paulhsia@chromium.org
Signed-off-by: Takashi Iwai
07 Nov, 2019
2 commits
-
…/broonie/sound into for-linus
ASoC: Fixes for v5.4
These are a collection of fixes since v5.4-rc4 that have accumilated,
they're all driver specific and there's nothing major in here so it's
probably not essential to actually send them but I'll leave that call to
you. -
The clean up commit 41672c0c24a6 ("ALSA: timer: Simplify error path in
snd_timer_open()") unified the error handling code paths with the
standard goto, but it introduced a subtle bug: the timer instance is
stored in snd_timer_open() incorrectly even if it returns an error.
This may eventually lead to UAF, as spotted by fuzzer.The culprit is the snd_timer_open() code checks the
SNDRV_TIMER_IFLG_EXCLUSIVE flag with the common variable timeri.
This variable is supposed to be the newly created instance, but we
(ab-)used it for a temporary check before the actual creation of a
timer instance. After that point, there is another check for the max
number of instances, and it bails out if over the threshold. Before
the refactoring above, it worked fine because the code returned
directly from that point. After the refactoring, however, it jumps to
the unified error path that stores the timeri variable in return --
even if it returns an error. Unfortunately this stored value is kept
in the caller side (snd_timer_user_tselect()) in tu->timeri. This
causes inconsistency later, as if the timer was successfully
assigned.In this patch, we fix it by not re-using timeri variable but a
temporary variable for testing the exclusive connection, so timeri
remains NULL at that point.Fixes: 41672c0c24a6 ("ALSA: timer: Simplify error path in snd_timer_open()")
Reported-and-tested-by: Tristan Madani
Cc:
Link: https://lore.kernel.org/r/20191106165547.23518-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
31 Oct, 2019
1 commit
-
When a card is disconnected while in use, the system waits until all
opened files are closed then releases the card. This is done via
put_device() of the card device in each device release code.The recently reported mutex deadlock bug happens in this code path;
snd_timer_close() for the timer device deals with the global
register_mutex and it calls put_device() there. When this timer
device is the last one, the card gets freed and it eventually calls
snd_timer_free(), which has again the protection with the global
register_mutex -- boom.Basically put_device() call itself is race-free, so a relative simple
workaround is to move this put_device() call out of the mutex. For
achieving that, in this patch, snd_timer_close_locked() got a new
argument to store the card device pointer in return, and each caller
invokes put_device() with the returned object after the mutex unlock.Reported-and-tested-by: Kirill A. Shutemov
Cc:
Signed-off-by: Takashi Iwai
21 Oct, 2019
1 commit
-
Parameter fragments and fragment_size are type of u32. U32_MAX is
the correct check.Signed-off-by: Xiaojun Sang
Signed-off-by: Srinivas Kandagatla
Acked-by: Vinod Koul
Link: https://lore.kernel.org/r/20191021095432.5639-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown
20 Sep, 2019
1 commit
-
Pull dma-mapping updates from Christoph Hellwig:
- add dma-mapping and block layer helpers to take care of IOMMU merging
for mmc plus subsequent fixups (Yoshihiro Shimoda)- rework handling of the pgprot bits for remapping (me)
- take care of the dma direct infrastructure for swiotlb-xen (me)
- improve the dma noncoherent remapping infrastructure (me)
- better defaults for ->mmap, ->get_sgtable and ->get_required_mask
(me)- cleanup mmaping of coherent DMA allocations (me)
- various misc cleanups (Andy Shevchenko, me)
* tag 'dma-mapping-5.4' of git://git.infradead.org/users/hch/dma-mapping: (41 commits)
mmc: renesas_sdhi_internal_dmac: Add MMC_CAP2_MERGE_CAPABLE
mmc: queue: Fix bigger segments usage
arm64: use asm-generic/dma-mapping.h
swiotlb-xen: merge xen_unmap_single into xen_swiotlb_unmap_page
swiotlb-xen: simplify cache maintainance
swiotlb-xen: use the same foreign page check everywhere
swiotlb-xen: remove xen_swiotlb_dma_mmap and xen_swiotlb_dma_get_sgtable
xen: remove the exports for xen_{create,destroy}_contiguous_region
xen/arm: remove xen_dma_ops
xen/arm: simplify dma_cache_maint
xen/arm: use dev_is_dma_coherent
xen/arm: consolidate page-coherent.h
xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance
arm: remove wrappers for the generic dma remap helpers
dma-mapping: introduce a dma_common_find_pages helper
dma-mapping: always use VM_DMA_COHERENT for generic DMA remap
vmalloc: lift the arm flag for coherent mappings to common code
dma-mapping: provide a better default ->get_required_mask
dma-mapping: remove the dma_declare_coherent_memory export
remoteproc: don't allow modular build
...
09 Sep, 2019
1 commit
04 Sep, 2019
1 commit
-
Replace the local hack with the dma_can_mmap helper to check if
a given device supports mapping DMA allocations to userspace.Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
28 Aug, 2019
1 commit
-
Most of the modern codecs supports 352.8KHz and 384KHz sample rates.
Currenlty HW params fails to set 352.8Kz and 384KHz sample rate
as these are not in known rates list.
Add these new rates to known list to allow them.This patch also adds defines in pcm.h so that drivers can use it.
Signed-off-by: Vidyakumar Athota
Signed-off-by: Banajit Goswami
Signed-off-by: Srinivas Kandagatla
Link: https://lore.kernel.org/r/20190822095653.7200-2-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown
25 Aug, 2019
1 commit
-
The input pool of a client might be deleted via the resize ioctl, the
the access to it should be covered by the proper locks. Currently the
only missing place is the call in snd_seq_ioctl_get_client_pool(), and
this patch papers over it.Reported-by: syzbot+4a75454b9ca2777f35c7@syzkaller.appspotmail.com
Cc:
Signed-off-by: Takashi Iwai
30 Jul, 2019
1 commit
-
lost wakeup can occur after enabling irq, therefore put task
into interruptible before enabling interrupts,without this change, task can be put to sleep and snd_pcm_drain
will delayFixes: f2b3614cefb6 ("ALSA: PCM - Don't check DMA time-out too shortly")
Signed-off-by: Yuki Tsunashima
Signed-off-by: Suresh Udipi
[ported from 4.9]
Signed-off-by: Adam Miartus
Signed-off-by: Takashi Iwai
23 Jul, 2019
4 commits
-
Draining makes little sense in the situation of hardware overrun, as the
hardware will have consumed all its available samples. Additionally,
draining whilst the stream is paused would presumably get stuck as no
data is being consumed on the DSP side.Signed-off-by: Charles Keepax
Acked-by: Vinod Koul
Signed-off-by: Takashi Iwai -
Partial drain and next track are intended for gapless playback and
don't really have an obvious interpretation for a capture stream, so
makes sense to not allow those operations on capture streams.Signed-off-by: Charles Keepax
Acked-by: Vinod Koul
Signed-off-by: Takashi Iwai -
Currently, whilst in SNDRV_PCM_STATE_OPEN it is possible to call
snd_compr_stop, snd_compr_drain and snd_compr_partial_drain, which
allow a transition to SNDRV_PCM_STATE_SETUP. The stream should
only be able to move to the setup state once it has received a
SNDRV_COMPRESS_SET_PARAMS ioctl. Fix this issue by not allowing
those ioctls whilst in the open state.Signed-off-by: Charles Keepax
Acked-by: Vinod Koul
Signed-off-by: Takashi Iwai -
A previous fix to the stop handling on compressed capture streams causes
some knock on issues. The previous fix updated snd_compr_drain_notify to
set the state back to PREPARED for capture streams. This causes some
issues however as the handling for snd_compr_poll differs between the
two states and some user-space applications were relying on the poll
failing after the stream had been stopped.To correct this regression whilst still fixing the original problem the
patch was addressing, update the capture handling to skip the PREPARED
state rather than skipping the SETUP state as it has done until now.Fixes: 4f2ab5e1d13d ("ALSA: compress: Fix stop handling on compressed capture streams")
Signed-off-by: Charles Keepax
Acked-by: Vinod Koul
Signed-off-by: Takashi Iwai
19 Jul, 2019
1 commit
-
The recent rewrite of PCM link lock management introduced the refcount
in snd_pcm_group object, managed by the kernel refcount_t API. This
caused unexpected kernel warnings when the kernel is built with
CONFIG_REFCOUNT_FULL=y. As the warning line indicates, the problem is
obviously that we start with refcount=0 and do refcount_inc() for
adding each PCM link, while refcount_t API doesn't like refcount_inc()
performed on zero.For adapting the proper refcount_t usage, this patch changes the logic
slightly:
- The initial refcount is 1, assuming the single list entry
- The refcount is incremented / decremented at each PCM link addition
and deletion
- ... which allows us concentrating only on the refcount as a release
conditionFixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204221
Reported-and-tested-by: Duncan Overbruck
Cc:
Signed-off-by: Takashi Iwai