From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E3D023A6B9D; Thu, 8 Oct 2026 10:16:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791454609; cv=none; b=FpHr3ksIbqDdxkuzGXPfXOhlIDv70XW25eVoV+AR3SP+64yykfkk4FVWnlDhcWaGuuvCax8z8Do0ZxGPVD2M6zrMSn6z7q3M0tLKkhAK1z8wmjol37IJwVNqK2/xqQKl2gJquaQuCdR4dxYdtM+9GxukrJaoTOGQmNHNC7OBG58= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791454609; c=relaxed/simple; bh=r69vVeNdhze51fjh/Cma97RFIwb+Ll+h1HuX/+1Tbnk=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ZtdSwCxaq9YGE+PJyflhS8JijM+AfoDSzbx4z47REb+CLh+erBkU1WEtrAVtk+qdRu6D0OWYyDZ1yuH7ycQU5lYpnOYHoyT43iNCZoYy86gaovhhc49kQxoYgiyJQRXN9o6b9PI/azGSnVjOMPwC4Jpc6jAiq46o616VlKDl3wc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id EB7DF21BD4; Thu, 8 Oct 2026 10:16:45 +0000 (UTC) Authentication-Results: smtp-out1.suse.de; none Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id B92DB1339F; Thu, 8 Oct 2026 10:16:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id PsYaJI1tx2qxNAAAD6G6ig (envelope-from ); Thu, 08 Oct 2026 10:16:45 +0000 Date: Thu, 08 Oct 2026 12:16:41 +0200 Message-ID: <87ik3c5wfq.wl-tiwai@suse.de> From: Takashi Iwai To: Cezary Rojewski Cc: Takashi Iwai , , Subject: Re: [PATCH 1/3] ALSA: hda: Stop unsol events and jack polling before codec unbind In-Reply-To: <7efc9ca8-b470-410c-b717-3c548bd196f1@intel.com> References: <20261007215650.159871-1-tiwai@suse.de> <20261007215650.159871-2-tiwai@suse.de> <7efc9ca8-b470-410c-b717-3c548bd196f1@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/30.2 Mule/6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spamd-Result: default: False [0.00 / 50.00] X-Spam-Score: 0.00 X-Spam-Flag: NO X-Spam-Level: X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason On Thu, 08 Oct 2026 11:08:13 +0200, Cezary Rojewski wrote: > > On 10/7/2026 11:56 PM, Takashi Iwai wrote: > > At unbinding a codec driver, hda_codec_driver_remove() calls the > > codec's remove callback that releases the driver resources, followed > > by snd_hda_codec_cleanup_for_unbind(). Meanwhile, the unsolicited > > events are processed asynchronously in bus->unsol_work, and > > snd_hdac_bus_process_unsol_events() checks only codec->registered flag > > before calling the driver's unsol_event callback without the lock. > > Since codec->registered is cleared only in > > snd_hda_codec_cleanup_for_unbind(), and there is no flush of the unsol > > work at unbinding, the unsol event handler may run concurrently during > > the running remove callback, which may lead to a UAF. The same > > problem applies to the jack polling work, which is canceled only after > > the remove callback. > > > +++ b/sound/hda/common/bind.c > > @@ -100,6 +100,9 @@ static int hda_codec_driver_probe(struct device *dev) > > if (WARN_ON(!codec->preset)) > > return -EINVAL; > > > > + /* unsol events are still blocked until registered */ > > + codec->core.unsol_disabled = false; > > + > > err = snd_hda_codec_set_name(codec, codec->preset->name); > > if (err < 0) > > goto error; > > @@ -160,6 +163,10 @@ static int hda_codec_driver_remove(struct device *dev) > > return codec->bus->core.ext_ops->hdev_detach(&codec->core); > > } > > > > + /* stop asynchronous jack handling before freeing driver resources */ > > + snd_hdac_device_disable_unsol(&codec->core); > > + cancel_delayed_work_sync(&codec->jackpoll_work); > > > IMHO this is a proof that ->registered flag doesn't do its job. > snd_hda_codec_cleanup_for_unbind() is called right after and it does > contain cancel_delayed_work_sync(&codec->jackpoll_work). It does > contain snd_hda_codec_disconnect_pcms() and > snd_hda_jack_tbl_disconnect() operations too. It's about the pending works, and the flag doesn't help there alone unless they are synchronized; at the time point you flip the flag, the work might be already in-flight, so the flag switch may miss the chances. > I'd say it is snd_hda_codec_cleanup_for_unbind() that needs an update > and perhaps be responsible for calling driver->remove() too. Yeah, some code reorganization would be good. thanks, Takashi