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 989F5C83F3F for ; Mon, 4 Sep 2023 14:08:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353105AbjIDOIX (ORCPT ); Mon, 4 Sep 2023 10:08:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231166AbjIDOIV (ORCPT ); Mon, 4 Sep 2023 10:08:21 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42D71CDB; Mon, 4 Sep 2023 07:08:17 -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 03C471F38C; Mon, 4 Sep 2023 14:08:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1693836496; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d5r04qVqTrOT2KJTqTw8pN2+2R0Bk1SAzGCxmHII/9E=; b=MrVmBVJEOPyfdtD7KdbhdFS/fssl93Ysfncpd73zI54VymUaQE4NO/WSjLZSTubRrwCDdf VXWlsodUJmmYImHhnyvWMSM/wFEI8mLeJdUz/xRC5pms9sR1Kjc6qm3sEu6/UknX2bKJ4E LPtsMwG56NhdqnK2nfmtW2lM9Cj6CkA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1693836496; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d5r04qVqTrOT2KJTqTw8pN2+2R0Bk1SAzGCxmHII/9E=; b=33G/3lZs1AP62zGxlniLVD2fPOGlxy9T/jeePvy2fhws4fhqZtd3S157lwWY6C2yC8ZyTv czLv0YeHmwuzSrDw== 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 CCF8C13425; Mon, 4 Sep 2023 14:08:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id mSnVMM/k9WR5IwAAMHmgww (envelope-from ); Mon, 04 Sep 2023 14:08:15 +0000 Date: Mon, 04 Sep 2023 16:08:15 +0200 Message-ID: <87ledmjak0.wl-tiwai@suse.de> From: Takashi Iwai To: Christophe JAILLET Cc: Jaroslav Kysela , Takashi Iwai , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [PATCH] ALSA: usb-audio: Fix a potential memory leak in scarlett2_init_notify() In-Reply-To: References: <871qffmj2d.wl-tiwai@suse.de> <8cde2320-517f-3a38-8c3f-f807791c6c52@wanadoo.fr> <87sf7vkybk.wl-tiwai@suse.de> 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=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 03 Sep 2023 21:42:55 +0200, Christophe JAILLET wrote: > > Le 03/09/2023 à 18:37, Takashi Iwai a écrit : > > On Sun, 03 Sep 2023 17:04:47 +0200, > ... > > > Indeed. The fix would be rather a oneliner like below, though: > > Looks much better than mine :) > > I let you send the patch, it is your solution. > > > > Just for my understanding, how is snd_ump_ops used, especially .open? > I've not been able to figure out where it was called. It's called via rawmidi open (the snd_ump_endpoint is a sort of child class of snd_rawmidi). > In alloc_midi_urbs(), if usb_alloc_coherent() fails, then > ctx->urb->transfer_buffer could be anything because usb_fill_xxx_urb() > is not called. > So there could be an edge case where your fix could still be incomplete. Each URB is allocated in the loop via usb_alloc_urb(), and it does zero-initialize the object, hence the buffer is supposed to be NULL until it's set up via usb_fill_xxx(). thanks, Takashi > For the start_input_streams() caller, this is fine, because the > corresponding memory is kzalloc()'ed in start_input_streams() at some > point, but I've not been able to check for snd_usb_midi_v2_open(). > > CJ > > > > > --- a/sound/usb/midi2.c > > +++ b/sound/usb/midi2.c > > @@ -265,7 +265,7 @@ static void free_midi_urbs(struct snd_usb_midi2_endpoint *ep) > > if (!ep) > > return; > > - for (i = 0; i < ep->num_urbs; ++i) { > > + for (i = 0; i < NUM_URBS; ++i) { > > ctx = &ep->urbs[i]; > > if (!ctx->urb) > > break; > > > > That was the intended behavior of free_midi_urbs(). > > > > > > Takashi > > >