Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2597349rwb; Mon, 19 Sep 2022 07:20:22 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6U768FTKXb/vWyUfWFYXoSTL1y8lV5UQPI+JyJxTa4LlgQ44Mr6U46+zw53flVpGacVp1o X-Received: by 2002:a17:902:b693:b0:178:5fa6:4b3 with SMTP id c19-20020a170902b69300b001785fa604b3mr13284393pls.63.1663597222558; Mon, 19 Sep 2022 07:20:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663597222; cv=none; d=google.com; s=arc-20160816; b=YE8nOKrvPyPsJLgoR3djcUzrSqkl0rdMJTitAFLAmbERRy4y1HcTLiwslYqI4AL9Hw n5P5swvmB4D5mruuSnx04HPsTIrcLp1gVLQw8slfr/oP3OHLOzf+Rb59HTMmh/jSsF/n cLJ/fLW+d7NfeNZgvx2iSZCBJ99/6UvwbisIgC9g38vsj5cNgk+Crxg6ka+Zmr3MLTuh +bpiv6H8rgjyirgmaDwBkfLCSLwPy6SWU+RH6VbBayWIEHcmtS4wjT0m8KFpQIuNpc6U o3tpx5mySt3yvyxnHAwpF8L6IyTDBpqM4DpI5jLP0MUjQLuA7BRZCdCQVUQxRzeTqG6p WfYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature:dkim-signature; bh=mG8qNqOUZiLVI5e04ilFKD8dzskLAhThKDItvZFPL00=; b=E8fLkFu5PAS6heJyVmmLzG4k6d1ksJo5Nwr6zIRC6XFYXxj3M11olH6Fkqa9Tqb6Nb eLytM7joZSApJp6MMlG45ISg5rmHFQ1Uax/kpKP9LBdYV0fKoE9KbpbEIP78YiiOPe9Y AX7Hpk+JM20GXcAy/94WZL5Rxm/p39OKZp0Faoss4W31dxuPkUydvr/rwntQBb3pOmYW vS0Tsj3JtfAYgdKYDlMbokT2nkI1YqWR7GD/eXh5rsWHLEgHWGCfQ2l4e1DXp66h+YXd 4ATSgcex2BB3bNh0DF+dJRhxgs2pjdOosX9te2ERGkqFWDtQzS7YpiAzWg6d59UkpSMt aetw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=mKlBuyMh; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m6-20020a1709026bc600b001780ba83636si28268142plt.612.2022.09.19.07.20.09; Mon, 19 Sep 2022 07:20:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=mKlBuyMh; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229586AbiISNtI (ORCPT + 99 others); Mon, 19 Sep 2022 09:49:08 -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 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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