Received-SPF: pass (google.com: domain of linux-kernel+bounces-167824-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <d9c5b863-53a5-4255-ab15-9ac3cb10ec10@opensource.cirrus.com>
Date: Fri, 3 May 2024 16:31:15 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] ALSA: hda/cs_dsp_ctl: Actually remove ALSA controls
To: Takashi Iwai <tiwai@suse.de>
CC: <tiwai@suse.com>, <linux-kernel@vger.kernel.org>,
        <patches@opensource.cirrus.com>, <alsa-devel@alsa-project.org>,
        <linux-sound@vger.kernel.org>
References: <20240503144920.61075-1-rf@opensource.cirrus.com>
 <87msp79b7o.wl-tiwai@suse.de>
Content-Language: en-GB
From: Richard Fitzgerald <rf@opensource.cirrus.com>
In-Reply-To: <87msp79b7o.wl-tiwai@suse.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

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.

> The structure is so complex and I can't follow immediately,
> unfortunately...
> 

Yes, I know. When this hda_cs_dsp_ctl code was first submitted to the
kernel you suggested using private_free instead of this manual cleanup
but for some reason that wasn't implemented.

> 
> thanks,
> 
> Takashi
> 
>> ---
>>   sound/pci/hda/hda_cs_dsp_ctl.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/sound/pci/hda/hda_cs_dsp_ctl.c b/sound/pci/hda/hda_cs_dsp_ctl.c
>> index 463ca06036bf..a42653d3473d 100644
>> --- a/sound/pci/hda/hda_cs_dsp_ctl.c
>> +++ b/sound/pci/hda/hda_cs_dsp_ctl.c
>> @@ -203,6 +203,10 @@ void hda_cs_dsp_control_remove(struct cs_dsp_coeff_ctl *cs_ctl)
>>   {
>>   	struct hda_cs_dsp_coeff_ctl *ctl = cs_ctl->priv;
>>   
>> +	/* Only public firmware controls will have an associated kcontrol */
>> +	if (ctl && ctl->kctl)
>> +		snd_ctl_remove(ctl->card, ctl->kctl);
>> +
>>   	kfree(ctl);
>>   }
>>   EXPORT_SYMBOL_NS_GPL(hda_cs_dsp_control_remove, SND_HDA_CS_DSP_CONTROLS);
>> -- 
>> 2.39.2
>>