<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/sound, branch v5.18.18</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.18.18</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.18.18'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2022-06-09T08:29:55Z</updated>
<entry>
<title>ASoC: cs35l41: Fix an out-of-bounds access in otp_packed_element_t</title>
<updated>2022-06-09T08:29:55Z</updated>
<author>
<name>Hui Wang</name>
<email>hui.wang@canonical.com</email>
</author>
<published>2022-03-28T12:35:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a59b9958416096dd21dc4f62b0c5be525d459ca8'/>
<id>urn:sha1:a59b9958416096dd21dc4f62b0c5be525d459ca8</id>
<content type='text'>
[ Upstream commit 9f342904216f378e88008bb0ce1ae200a4b99fe8 ]

The CS35L41_NUM_OTP_ELEM is 100, but only 99 entries are defined in
the array otp_map_1/2[CS35L41_NUM_OTP_ELEM], this will trigger UBSAN
to report a shift-out-of-bounds warning in the cs35l41_otp_unpack()
since the last entry in the array will result in GENMASK(-1, 0).

UBSAN reports this problem:
 UBSAN: shift-out-of-bounds in /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8
 shift exponent 64 is too large for 64-bit type 'long unsigned int'
 CPU: 10 PID: 595 Comm: systemd-udevd Not tainted 5.15.0-23-generic #23
 Hardware name: LENOVO \x02MFG_IN_GO/\x02MFG_IN_GO, BIOS N3GET19W (1.00 ) 03/11/2022
 Call Trace:
  &lt;TASK&gt;
  show_stack+0x52/0x58
  dump_stack_lvl+0x4a/0x5f
  dump_stack+0x10/0x12
  ubsan_epilogue+0x9/0x45
  __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef
  ? regmap_unlock_mutex+0xe/0x10
  cs35l41_otp_unpack.cold+0x1c6/0x2b2 [snd_soc_cs35l41_lib]
  cs35l41_hda_probe+0x24f/0x33a [snd_hda_scodec_cs35l41]
  cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c]
  ? cs35l41_hda_i2c_remove+0x20/0x20 [snd_hda_scodec_cs35l41_i2c]
  i2c_device_probe+0x252/0x2b0

Fixes: 6450ef559056 ("ASoC: cs35l41: CS35L41 Boosted Smart Amplifier")
Reviewed-by: Lucas Tanure &lt;tanureal@opensource.cirrus.com&gt;
Acked-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Signed-off-by: Hui Wang &lt;hui.wang@canonical.com&gt;
Link: https://lore.kernel.org/r/20220328123535.50000-2-hui.wang@canonical.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: jack: Access input_dev under mutex</title>
<updated>2022-06-09T08:29:34Z</updated>
<author>
<name>Amadeusz Sławiński</name>
<email>amadeuszx.slawinski@linux.intel.com</email>
</author>
<published>2022-04-12T09:16:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=582aea6084cc59fec881204f026816d1219f2348'/>
<id>urn:sha1:582aea6084cc59fec881204f026816d1219f2348</id>
<content type='text'>
[ Upstream commit 1b6a6fc5280e97559287b61eade2d4b363e836f2 ]

It is possible when using ASoC that input_dev is unregistered while
calling snd_jack_report, which causes NULL pointer dereference.
In order to prevent this serialize access to input_dev using mutex lock.

Signed-off-by: Amadeusz Sławiński &lt;amadeuszx.slawinski@linux.intel.com&gt;
Reviewed-by: Cezary Rojewski &lt;cezary.rojewski@intel.com&gt;
Link: https://lore.kernel.org/r/20220412091628.3056922-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'asoc-fix-v5.18-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus</title>
<updated>2022-04-19T15:26:01Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2022-04-19T15:26:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0aea30a07ec6b50de0fc5f5b2ec34a68ead86b61'/>
<id>urn:sha1:0aea30a07ec6b50de0fc5f5b2ec34a68ead86b61</id>
<content type='text'>
ASoC: Fixes for v5.18

A collection of fixes that came in since the merge window, plus one new
device ID for an x86 laptop.  Nothing that really stands out with
particularly big impact outside of the affected device.
</content>
</entry>
<entry>
<title>ALSA: memalloc: Add fallback SG-buffer allocations for x86</title>
<updated>2022-04-13T05:48:53Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2022-04-13T05:48:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=925ca893b4a65177394581737b95d03fea2660f2'/>
<id>urn:sha1:925ca893b4a65177394581737b95d03fea2660f2</id>
<content type='text'>
The recent change for memory allocator replaced the SG-buffer handling
helper for x86 with the standard non-contiguous page handler.  This
works for most cases, but there is a corner case I obviously
overlooked, namely, the fallback of non-contiguous handler without
IOMMU.  When the system runs without IOMMU, the core handler tries to
use the continuous pages with a single SGL entry.  It works nicely for
most cases, but when the system memory gets fragmented, the large
allocation may fail frequently.

Ideally the non-contig handler could deal with the proper SG pages,
it's cumbersome to extend for now.  As a workaround, here we add new
types for (minimalistic) SG allocations, instead, so that the
allocator falls back to those types automatically when the allocation
with the standard API failed.

BTW, one better (but pretty minor) improvement from the previous
SG-buffer code is that this provides the proper mmap support without
the PCM's page fault handling.

Fixes: 2c95b92ecd92 ("ALSA: memalloc: Unify x86 SG-buffer handling (take#3)")
BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2272
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1198248
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20220413054808.7547-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ALSA: core: Add snd_card_free_on_error() helper</title>
<updated>2022-04-12T09:47:57Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2022-04-12T09:31:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fee2b871d8d6389c9b4bdf9346a99ccc1c98c9b8'/>
<id>urn:sha1:fee2b871d8d6389c9b4bdf9346a99ccc1c98c9b8</id>
<content type='text'>
This is a small helper function to handle the error path more easily
when an error happens during the probe for the device with the
device-managed card.  Since devres releases in the reverser order of
the creations, usually snd_card_free() gets called at the last in the
probe error path unless it already reached snd_card_register() calls.
Due to this nature, when a driver expects the resource releases in
card-&gt;private_free, this might be called too lately.

As a workaround, one should call the probe like:

 static int __some_probe(...) { // do real probe.... }

 static int some_probe(...)
 {
	return snd_card_free_on_error(dev, __some_probe(dev, ...));
 }

so that the snd_card_free() is called explicitly at the beginning of
the error path from the probe.

This function will be used in the upcoming fixes to address the
regressions by devres usages.

Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation")
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20220412093141.8008-2-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>ASoC: soc-core: add debugfs_prefix member to snd_soc_component_driver</title>
<updated>2022-04-05T18:14:20Z</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2022-03-09T20:21:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d462f6ed2aeac30c0b440a91fb05d964956935f9'/>
<id>urn:sha1:d462f6ed2aeac30c0b440a91fb05d964956935f9</id>
<content type='text'>
Allow the component debugfs_prefix to be set from
snd_soc_component_driver. First use case is avoiding a duplicate
debugfs entry error in case a device has multiple components
which have the same name therefore.

Note that we don't set component-&gt;debugfs_prefix if it's set already.
That's needed because partially component-&gt;debugfs_prefix is set
before calling snd_soc_component_initialize().

Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Link: https://lore.kernel.org/r/d18bff6a-1df1-5f95-0cf8-10dbaa62d7be@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'sound-fix-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound</title>
<updated>2022-04-01T17:32:46Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-04-01T17:32:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d0d642a5d365b5e2295950fd184d5d1f630896dd'/>
<id>urn:sha1:d0d642a5d365b5e2295950fd184d5d1f630896dd</id>
<content type='text'>
Pull sound fixes from Takashi Iwai:
 "Just a few fixes that have been gathered since the previous pull:

   - An additional fix for potential PCM deadlocks

   - A series of HD-audio CS8409 codec patches for new models

   - Other device specific fixes for HD-audio, ASoC mediatek, Intel,
     fsl, rockchip"

* tag 'sound-fix-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock
  ALSA: hda: Avoid unsol event during RPM suspending
  ALSA: hda/realtek: Fix audio regression on Mi Notebook Pro 2020
  ALSA: hda/cs8409: Add new Dolphin HW variants
  ALSA: hda/cs8409: Disable HSBIAS_SENSE_EN for Cyborg
  ALSA: hda/cs8409: Support new Warlock MLK Variants
  ALSA: hda/cs8409: Fix Full Scale Volume setting for all variants
  ALSA: hda/cs8409: Re-order quirk table into ascending order
  ALSA: hda/cs8409: Fix Warlock to use mono mic configuration
  ALSA: cs4236: fix an incorrect NULL check on list iterator
  ALSA: hda/realtek: Enable headset mic on Lenovo P360
  ASoC: SOF: Intel: Fix build error without SND_SOC_SOF_PCI_DEV
  ALSA: hda/realtek: Add mute and micmut LED support for Zbook Fury 17 G9
  ASoC: rockchip: i2s_tdm: Fixup config for SND_SOC_DAIFMT_DSP_A/B
  ASoC: fsl-asoc-card: Fix jack_event() always return 0
  ASoC: mediatek: mt6358: add missing EXPORT_SYMBOLs
</content>
</entry>
<entry>
<title>ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock</title>
<updated>2022-03-30T12:29:49Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2022-03-30T12:09:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bc55cfd5718c7c23e5524582e9fa70b4d10f2433'/>
<id>urn:sha1:bc55cfd5718c7c23e5524582e9fa70b4d10f2433</id>
<content type='text'>
syzbot caught a potential deadlock between the PCM
runtime-&gt;buffer_mutex and the mm-&gt;mmap_lock.  It was brought by the
recent fix to cover the racy read/write and other ioctls, and in that
commit, I overlooked a (hopefully only) corner case that may take the
revert lock, namely, the OSS mmap.  The OSS mmap operation
exceptionally allows to re-configure the parameters inside the OSS
mmap syscall, where mm-&gt;mmap_mutex is already held.  Meanwhile, the
copy_from/to_user calls at read/write operations also take the
mm-&gt;mmap_lock internally, hence it may lead to a AB/BA deadlock.

A similar problem was already seen in the past and we fixed it with a
refcount (in commit b248371628aa).  The former fix covered only the
call paths with OSS read/write and OSS ioctls, while we need to cover
the concurrent access via both ALSA and OSS APIs now.

This patch addresses the problem above by replacing the buffer_mutex
lock in the read/write operations with a refcount similar as we've
used for OSS.  The new field, runtime-&gt;buffer_accessing, keeps the
number of concurrent read/write operations.  Unlike the former
buffer_mutex protection, this protects only around the
copy_from/to_user() calls; the other codes are basically protected by
the PCM stream lock.  The refcount can be a negative, meaning blocked
by the ioctls.  If a negative value is seen, the read/write aborts
with -EBUSY.  In the ioctl side, OTOH, they check this refcount, too,
and set to a negative value for blocking unless it's already being
accessed.

Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com
Fixes: dca947d4d26d ("ALSA: pcm: Fix races among concurrent read/write and buffer changes")
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com
Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'flexible-array-transformations-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux</title>
<updated>2022-03-24T18:39:32Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-03-24T18:39:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3ce62cf4dc3b01d1cbee1293049ca5d4c7d6d749'/>
<id>urn:sha1:3ce62cf4dc3b01d1cbee1293049ca5d4c7d6d749</id>
<content type='text'>
Pull flexible-array transformations from Gustavo Silva:
 "Treewide patch that replaces zero-length arrays with flexible-array
  members.

  This has been baking in linux-next for a whole development cycle"

* tag 'flexible-array-transformations-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux:
  treewide: Replace zero-length arrays with flexible-array members
</content>
</entry>
<entry>
<title>ALSA: pcm: Fix races among concurrent hw_params and hw_free calls</title>
<updated>2022-03-22T19:56:07Z</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2022-03-22T17:07:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=92ee3c60ec9fe64404dc035e7c41277d74aa26cb'/>
<id>urn:sha1:92ee3c60ec9fe64404dc035e7c41277d74aa26cb</id>
<content type='text'>
Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF.  Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.

This patch introduced a new mutex, runtime-&gt;buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths.  Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity.

Reported-by: Hu Jiahui &lt;kirin.say@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Jaroslav Kysela &lt;perex@perex.cz&gt;
Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
</content>
</entry>
</feed>
