Embedding the ctl_dev in the snd_card object may result in UAF when
the delayed kobj release is used; at the delayed kobj release, it
still accesses the struct device itself while the card memory (that
embeds the struct device) may be already gone.

As a workaround, detach the struct device from the card object by
allocating via the new snd_device_alloc() helper.  The rest are just
replacing ctl_dev access to the pointer.

This is based on the fix Curtis posted initially.  In this patch, the
changes are split and use the new helper function instead.

Link: https://lore.kernel.org/r/20230801171928.1460120-1-cujomalainey@chromium.org
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20230816160252.23396-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Now all needed callers have been replaced with *_locked() versions,
let's turn on the locking in snd_ctl_find_id() and
snd_ctl_find_numid().

This patch also adds the lockdep assertions for debugging, too.

Link: https://lore.kernel.org/r/20230718141304.1032-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

For reducing the unnecessary use of controls_rwsem in the drivers,
this patch adds a new variant for snd_ctl_find_*() helpers:
snd_ctl_find_id_locked() and snd_ctl_find_numid_locked() look for a
kctl element inside the card->controls_rwsem -- that is, doing the
very same as what snd_ctl_find_id() and snd_ctl_find_numid() did until
now.  snd_ctl_find_id() and snd_ctl_find_numid() remain same,
i.e. still unlocked version, but they will be switched to locked
version once after all callers are replaced.

The patch also replaces the calls of snd_ctl_find_id() and
snd_ctl_find_numid() in a few places; all of those are places where we
know that the functions are called properly with controls_rwsem held.
All others are without rwsem (although they should have been).

After this patch, we'll turn on the locking in snd_ctl_find_id() and
snd_ctl_find_numid() to be more race-free.

Link: https://lore.kernel.org/r/20230718141304.1032-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The id object passed to snd_ctl_find_id() is only read, and we can
mark it with const gracefully.

Link: https://lore.kernel.org/r/20230718141304.1032-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

To assure the proper locking, add the lockdep check to
__snd_ctl_remove(), __snd_ctl_add_replace() and other internal
functions to handle user controls.

Link: https://lore.kernel.org/r/20230718141304.1032-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

So far, snd_ctl_remove() requires its caller to take
card->controls_rwsem manually before the call for avoiding possible
races.  However, many callers don't care and miss the locking.

Basically it's cumbersome and error-prone to enforce it to each
caller.  Moreover, card->controls_rwsem is a field that should be used
only by internal or proper helpers, and it's not to be touched at
random external places.

This patch is an attempt to make those calls more consistent: now
snd_ctl_remove() takes the card->controls_rwsem internally, just like
other API functions for kctls.  Since a few callers already take the
controls_rwsem locks, the patch removes those locks at the same time,
too.

Link: https://lore.kernel.org/r/20230718141304.1032-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

snd_ctl_rename() expects that card->controls_rwsem is held in the
caller side for avoiding possible races, but actually no one really
did that.  It's likely because this operation is done usually only at
the device initialization where no race can happen.  But, it's still
safer to take a lock, so we just take the lock inside snd_ctl_rename()
like most of other API functions do.

Link: https://lore.kernel.org/r/20230718141304.1032-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

We don't need to change the numid at each time snd_ctl_rename_id() is
called, as the control element size itself doesn't change.  Let's keep
the previous numid value.

Along with it, add a note about calling this function only in the
card init phase.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606094035.14808-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Takes rwsem lock inside snd_ctl_elem_read instead of snd_ctl_elem_read_user
like it was done for write in commit 1fa4445f9adf1 ("ALSA: control - introduce
snd_ctl_notify_one() helper"). Doing this way we are also fixing the following
locking issue happening in the compat path which can be easily triggered and
turned into an use-after-free.

64-bits:
snd_ctl_ioctl
  snd_ctl_elem_read_user
    [takes controls_rwsem]
    snd_ctl_elem_read [lock properly held, all good]
    [drops controls_rwsem]

32-bits:
snd_ctl_ioctl_compat
  snd_ctl_elem_write_read_compat
    ctl_elem_write_read
      snd_ctl_elem_read [missing lock, not good]

CVE-2023-0266 was assigned for this issue.

Cc: stable@kernel.org # 5.13+
Signed-off-by: Clement Lecigne <clecigne@google.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230113120745.25464-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a snd_ctl_rename() function that takes care of updating the control
hash entries for callers that already have the relevant struct snd_kcontrol
at hand and hold the control write lock (or simply haven't registered the
card yet).

Fixes: c27e1efb61c5 ("ALSA: control: Use xarray for faster lookups")
Cc: stable@vger.kernel.org
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Link: https://lore.kernel.org/r/4170b71117ea81357a4f7eb8410f7cde20836c70.1666296963.git.maciej.szmigiero@oracle.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>