linux-kernel - Re: [PATCH] ALSA: hda/cs_dsp_ctl: Actually remove ALSA controls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87bk5man1c.wl-tiwai@suse.de>
Date: Fri, 03 May 2024 18:16:31 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc: <tiwai@...e.com>,
	<linux-kernel@...r.kernel.org>,
	<patches@...nsource.cirrus.com>,
	<alsa-devel@...a-project.org>,
	<linux-sound@...r.kernel.org>
Subject: Re: [PATCH] ALSA: hda/cs_dsp_ctl: Actually remove ALSA controls

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@...nsource.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;
 }