From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) (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 D02293C4163; Sat, 17 Oct 2026 10:31:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792233122; cv=none; b=gkxmRiwywh8CcbQtIILFs6MvVdKDrwdaUIDJcGw9gL52tuqV+i74oVKKPalQNtrKlAbclVZlAYs+CISlmytLY4bkiPsuadQWaGYEFTRpZznRYVNjSf03T/+yrbA5cjpVaDrlQ37FU2/xu6obvTu9N3KyaWY2E2s3vBSDtGw3RyE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792233122; c=relaxed/simple; bh=8Sam++QywWms/RRrPwse85nq2TJkglcFx6i2zC73XS0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=XQgS/GHjGTKLiYT+KM9jB4sjuX3oZBi1zn6rfjBgQAipP3yQQEfye3E9XJMjbQEdUHnCe7H2K1Il+Ni8EOSECa0a5ZBoGTl0VVpFL0gRVh8jBfu+16Xe5Nfe/W/UoblLnSi4Vji8XAMsoTfzsoS95wXyr+YJn21HgueSNVcAnZI= 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; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=GIsnDzO+; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=rwGfSIWo; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=BN6UyB6j; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=kDuuGrI+; arc=none smtp.client-ip=195.135.223.131 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="GIsnDzO+"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="rwGfSIWo"; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="BN6UyB6j"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="kDuuGrI+" 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-out2.suse.de (Postfix) with ESMTPS id 77A911F44F; Sat, 17 Oct 2026 10:31:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1792233116; 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=FHaH74bOf21j9DIx0c01Sl3r4QEftpKhFzhthKWkkNI=; b=GIsnDzO+ourOXl12ZSznPofHNWkeZ+cyJnec4rNKOWym9JGcM3ftG/AdRX+YDBqwLN9tQJ W73c51mDbqFPncGpWgMaDWzspc3JNsY8ENrmC0mGnLXv8AMps06FV1kR+4w4FWeArc8tAo Py2A0yzrCR8HC+qxQyaJGau1DlB1QR8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792233116; 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=FHaH74bOf21j9DIx0c01Sl3r4QEftpKhFzhthKWkkNI=; b=rwGfSIWoJRYxKBhjHCeOOgrSoL6Q+4KUoprnJ+wWvui9Cnp1qlmYKnZxE7wLQXUoQ5NprL ucRekuK7NyCvmWAg== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1792233115; 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=FHaH74bOf21j9DIx0c01Sl3r4QEftpKhFzhthKWkkNI=; b=BN6UyB6jmFd39hOyTDh6lr1RHFrbU4XAqqLI79UfZJmsmzgjUYiJam2nbprN0i1bIQZgeN ifFWcG2HPr9dZ71DV9wFOt1PG79mJOD5co+W22/r9MYH/xYoswCD6dIw4q7B4WsPk3IP30 M8bh5ZqLOYxruUASDNCLG9luk+bmmO0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1792233115; 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=FHaH74bOf21j9DIx0c01Sl3r4QEftpKhFzhthKWkkNI=; b=kDuuGrI+Xc/y0Hs5JSohN/B3BOwoTeufksafqdFI0y92qOMeE0F2VPGWiU1sKV2/rcPfxj hwF7KHECTZijh/Dg== 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 1E498133A7; Sat, 17 Oct 2026 10:31:55 +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 O2fKOZpO02pAJAAAD6G6ig (envelope-from ); Sat, 17 Oct 2026 10:31:55 +0000 Date: Sat, 17 Oct 2026 12:31:54 +0200 Message-ID: <87ecdo1uud.wl-tiwai@suse.de> From: Takashi Iwai To: Cen Zhang Cc: Takashi Iwai , perex@perex.cz, tiwai@suse.com, linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, jjzuming@gmail.com Subject: Re: [PATCH] ALSA: info: Serialize freeing with recursive registration In-Reply-To: References: <87ld7w20ok.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/30.2 Mule/6.0 Precedence: bulk X-Mailing-List: linux-sound@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-Spamd-Result: default: False [-3.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_CC(0.00)[suse.de,perex.cz,suse.com,vger.kernel.org,gmail.com]; RCPT_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo] X-Spam-Score: -3.30 X-Spam-Level: X-Spam-Flag: NO On Sat, 17 Oct 2026 11:27:54 +0200, Cen Zhang wrote: > > Hi Takashi, > > > > > Does the above crash really happen with unmodified code? > > The PCM oss proc unregister is per card, hence there can't be race > > between register and unregister for the same card. > > > > The hardening itself in the proc code is good, per se (although it's > > doubtful whether we really need a global mutex from the performance > > POV), though. > > > > > > thanks, > > > > Takashi > > > Thank you for the review. The quoted KASAN report used scheduling > instrumentation > and a small test module that called snd_card_register() on an already registered > dummy card. > > But reviewing the source, I found a concrete scenario involving > existing in-tree callers that appears to allow this race. > > Consider a registered card with PCM A and its published OSS proc > entry. A later bind of another codec B on the same card can reach > hda_codec_driver_probe(), which calls snd_card_register() when > !bus_probing && card->registered. > > At the same time, snd-pcm-oss can be unloaded while the card remains > registered, provided no active OSS references prevent the unload. > alsa_pcm_oss_exit() calls snd_pcm_notify(..., 1), which invokes > n_unregister() for the registered PCM devices and frees their OSS > proc entries. > > The interleaving I believe the source permits is: > > HDA codec B probe snd-pcm-oss module exit > ----------------- ----------------------- > snd_card_register(card) > snd_device_register_all(card) > /* PCM register_mutex released */ > > lock(register_mutex) > n_unregister(PCM A) > snd_info_free_entry(entry) > proc_remove(entry->p) > lock(info_mutex) > entry->p = NULL > unlock(info_mutex) > /* entry still linked */ > > lock(snd_card_mutex) > snd_info_card_register(card) > snd_info_register(card->proc_root) > find PCM A's linked entry > lock(info_mutex) > recreate proc node with > entry as private data > unlock(info_mutex) > unlock(snd_card_mutex) > > unlink entry > kfree(entry) > unlock(register_mutex) > > The card-info traversal does not hold the PCM register_mutex, and > OSS notifier removal does not take snd_card_mutex. The parent proc > directories also remain present because the card and PCM A have > not been removed. > > This appears to allow the new proc node to retain a pointer to the > freed entry. A subsequent open could then reach alloc_info_private() > with that stale pointer. Please let me know if I have overlooked > another serialization point in this path. OK, the arbitrary OSS removal is the problem child. IMO, instead of hardening piece-by-piece in ad hoc ways, we can pin the OSS PCM and mixer module when any card is added and unpin at the card removal, so that we can't unload OSS modules while there are any actually used cards. The cases with the partial HDA codec probe/remove is a different problem, though. This has to be addressed somehow better. thanks, Takashi