From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5090ECAAD3 for ; Mon, 19 Sep 2022 13:49:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229775AbiISNtJ (ORCPT ); Mon, 19 Sep 2022 09:49:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229580AbiISNtF (ORCPT ); Mon, 19 Sep 2022 09:49:05 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F40B52B269 for ; Mon, 19 Sep 2022 06:49:04 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id ACD5E1F8EF; Mon, 19 Sep 2022 13:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1663595343; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mG8qNqOUZiLVI5e04ilFKD8dzskLAhThKDItvZFPL00=; b=mKlBuyMhaxiEWWeeZ36dGVKdOLUJsvi/v7udtA+L3KRnmaHO6TbprWfdEkd9QP638w4EVs vctaMH5rD/8wo7ZmD6zqwwPQo4xdlHZTUfdpyqyZk9n+m1DMnrGNvkSQpwcgI1i08/C4hV KP5Xqw34gzOeedfakPutSRCsg1svaWg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1663595343; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mG8qNqOUZiLVI5e04ilFKD8dzskLAhThKDItvZFPL00=; b=tL2lQSkOYWYPav1/k/EEQYv6+oBt1pfIJhl/g4139XzF4FNrSqZvwFThX+wGS8oKkNpD4f w2hvtTZvwVAVNvAw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8923F13ABD; Mon, 19 Sep 2022 13:49:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NqW7IE9zKGO5TwAAMHmgww (envelope-from ); Mon, 19 Sep 2022 13:49:03 +0000 Date: Mon, 19 Sep 2022 15:49:02 +0200 Message-ID: <87y1ufh3u9.wl-tiwai@suse.de> From: Takashi Iwai To: Rondreis Cc: perex@perex.cz, tiwai@suse.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: possible deadlock in snd_rawmidi_free In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 19 Sep 2022 14:46:13 +0200, Rondreis wrote: > > Hello, > > When fuzzing the Linux kernel driver v6.0-rc4, the following crash was > triggered. > > HEAD commit: 7e18e42e4b280c85b76967a9106a13ca61c16179 > git tree: upstream > > kernel config: https://pastebin.com/raw/xtrgsXP3 > console output: https://pastebin.com/raw/9tabWDtu > > Sorry for failing to extract the reproducer, and the crash occurred at > the moment of disconnecting the midi device. On other versions of > Linux, I also triggered this crash. > > I would appreciate it if you have any idea how to solve this bug. I think there are two ways to work around it. The first one is to move the unregister_sound*() calls out of the sound_oss_mutex, something like: -- 8< -- --- a/sound/core/sound_oss.c +++ b/sound/core/sound_oss.c @@ -162,7 +162,6 @@ int snd_unregister_oss_device(int type, struct snd_card *card, int dev) mutex_unlock(&sound_oss_mutex); return -ENOENT; } - unregister_sound_special(minor); switch (SNDRV_MINOR_OSS_DEVICE(minor)) { case SNDRV_MINOR_OSS_PCM: track2 = SNDRV_MINOR_OSS(cidx, SNDRV_MINOR_OSS_AUDIO); @@ -174,12 +173,18 @@ int snd_unregister_oss_device(int type, struct snd_card *card, int dev) track2 = SNDRV_MINOR_OSS(cidx, SNDRV_MINOR_OSS_DMMIDI1); break; } - if (track2 >= 0) { - unregister_sound_special(track2); + if (track2 >= 0) snd_oss_minors[track2] = NULL; - } snd_oss_minors[minor] = NULL; mutex_unlock(&sound_oss_mutex); + + /* call unregister_sound_special() outside sound_oss_mutex; + * otherwise may deadlock, as it can trigger the release of a card + */ + unregister_sound_special(minor); + if (track2 >= 0) + unregister_sound_special(track2); + kfree(mptr); return 0; } -- 8< -- This should be OK, as the unregister_sound_*() itself can be called concurrently. Another workaround would be just to remove the register_mutex call at snd_rawmidi_free(), e.g. something like: -- 8< -- --- a/sound/core/rawmidi.c +++ b/sound/core/rawmidi.c @@ -1899,10 +1899,8 @@ static int snd_rawmidi_free(struct snd_rawmidi *rmidi) snd_info_free_entry(rmidi->proc_entry); rmidi->proc_entry = NULL; - mutex_lock(®ister_mutex); if (rmidi->ops && rmidi->ops->dev_unregister) rmidi->ops->dev_unregister(rmidi); - mutex_unlock(®ister_mutex); snd_rawmidi_free_substreams(&rmidi->streams[SNDRV_RAWMIDI_STREAM_INPUT]); snd_rawmidi_free_substreams(&rmidi->streams[SNDRV_RAWMIDI_STREAM_OUTPUT]); -- 8< -- This register_mutex there should be superfluous since the device has been already processed and detached by snd_rawmidi_dev_disconnect() beforehand. But if the first one is confirmed to work, the second one can be left untouched. thanks, Takashi