From: Takashi Iwai <tiwai@suse.de>
To: Richard Fitzgerald <rf@opensource.cirrus.com>
Cc: <tiwai@suse.com>, <linux-kernel@vger.kernel.org>,
<patches@opensource.cirrus.com>, <alsa-devel@alsa-project.org>,
<linux-sound@vger.kernel.org>
Subject: Re: [PATCH] ALSA: hda/cs_dsp_ctl: Actually remove ALSA controls
Date: Fri, 03 May 2024 18:16:31 +0200 [thread overview]
Message-ID: <87bk5man1c.wl-tiwai@suse.de> (raw)
In-Reply-To: <d9c5b863-53a5-4255-ab15-9ac3cb10ec10@opensource.cirrus.com>
On Fri, 03 May 2024 17:31:15 +0200,
Richard Fitzgerald wrote:
>
> On 03/05/2024 16:17, Takashi Iwai wrote:
> > On Fri, 03 May 2024 16:49:20 +0200,
> > Richard Fitzgerald wrote:
> >>
> >> hda_cs_dsp_control_remove() must remove the ALSA control when
> >> deleting all the infrastructure for handling the control.
> >>
> >> Without this it is possible for ALSA controls to be left in
> >> the Soundcard after the amp driver module has been unloaded.
> >> So the get/set callbacks point to code that no longer exists.
> >>
> >> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> >> Fixes: 3233b978af23 ("ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls")
> >> ---
> >> Note: it would be better to use the control private_free to do the
> >> cleanup, and that is my plan long-term. But that is a larger change
> >> to the code.
> >>
> >> I like to keep bugfix patches as simple as possible so they are
> >> low-risk and easy to cherry-pick into older kernels. So this patch
> >> fixes the bug. Sometime I will send a patch for future kernel
> >> versions that reworks the cleanup to use private_free.
> >
> > I also like to keep as simple as possible :)
> >
> > One slight concern is whether cs_dsp kctls can be deleted at the
> > snd_card removal (disconnect) before this function gets called.
> > That is, snd_card_free() of the main card may delete all associated
> > kctls, and may this function be called afterwards?
> > If yes, this change would lead to a UAF.
> >
>
> That's a good question. This is is safe for the cs35l56 driver because
> if the soundcard (or HDA codec driver) is removed, the HDA codec will
> destroy the component binding in its HDA_FIXUP_ACT_FREE. This will cause
> an unbind() call to the amp driver, which will (indirectly) call this
> function to remove all the controls. So they will have been removed
> before the soundcard is cleaned up.
>
> But it turns out that the cs35l41 driver doesn't clean up the cs_dsp
> instance in its unbind() call so the controls _won't_ be cleaned up
> and a double-free is possible. The firmware handling in the cs35l41
> driver is strange and confusing so I'm not sure whether this is a bug
> or something necessary.
OK, then setting kctl->private_free additionally like below could work
around it, I suppose.
Takashi
--- a/sound/pci/hda/hda_cs_dsp_ctl.c
+++ b/sound/pci/hda/hda_cs_dsp_ctl.c
@@ -97,6 +97,14 @@ static unsigned int wmfw_convert_flags(unsigned int in)
return out;
}
+static void hda_cs_dsp_coeff_free(struct snd_kcontrol *kctl)
+{
+ struct hda_cs_dsp_coeff_ctl *ctl = snd_kcontrol_chip(kctl);
+
+ if (ctl)
+ ctl->kctl = NULL;
+}
+
static void hda_cs_dsp_add_kcontrol(struct hda_cs_dsp_coeff_ctl *ctl, const char *name)
{
struct cs_dsp_coeff_ctl *cs_ctl = ctl->cs_ctl;
@@ -130,6 +138,7 @@ static void hda_cs_dsp_add_kcontrol(struct hda_cs_dsp_coeff_ctl *ctl, const char
}
dev_dbg(cs_ctl->dsp->dev, "Added KControl: %s\n", kcontrol.name);
+ kctl->private_free = hda_cs_dsp_coeff_free;
ctl->kctl = kctl;
}
prev parent reply other threads:[~2024-05-03 16:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 14:49 [PATCH] ALSA: hda/cs_dsp_ctl: Actually remove ALSA controls Richard Fitzgerald
2024-05-03 15:17 ` Takashi Iwai
2024-05-03 15:31 ` Richard Fitzgerald
2024-05-03 16:16 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bk5man1c.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=rf@opensource.cirrus.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).