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 DE9EBC433F5 for ; Tue, 11 Oct 2022 07:06:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229547AbiJKHGn (ORCPT ); Tue, 11 Oct 2022 03:06:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229489AbiJKHGh (ORCPT ); Tue, 11 Oct 2022 03:06:37 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECA0F7A52C; Tue, 11 Oct 2022 00:06:35 -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 5BDB51F747; Tue, 11 Oct 2022 07:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1665471994; 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=tqfif8iSWUHQtAaHeca22wqGv+/5oCq+njy7CTzwmnw=; b=AxT8QBWUVZGexrsbtGip33nkbHc/JP51xsZhet8Y+sc+kCtsmP534ux9y3p2OZfhuz238s zur5/tvHRJt6KYExHKbJc0sulRuVWzpNGymmbWe9CFKNc3S9hq/GMyM5GTbIupHjviRFog VqQ0Fpc4uKTyttX1HOPJB/646N6/0BY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1665471994; 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=tqfif8iSWUHQtAaHeca22wqGv+/5oCq+njy7CTzwmnw=; b=UoSLskXKkzSTCOQkXc4j10CF0vXs5KID+lCHiuolKGSkNodbzTE3g6EsHH/i4fLsoK7Upz 3QGx535wjOTUUHBw== 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 2F218139ED; Tue, 11 Oct 2022 07:06:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id INewCvoVRWPrfgAAMHmgww (envelope-from ); Tue, 11 Oct 2022 07:06:34 +0000 Date: Tue, 11 Oct 2022 09:06:33 +0200 Message-ID: <87k056dekm.wl-tiwai@suse.de> From: Takashi Iwai To: Mauro Carvalho Chehab Cc: Hyunwoo Kim , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] media: dvb-core: Fix UAF due to refcount races at releasing In-Reply-To: <87sfklgozd.wl-tiwai@suse.de> References: <20220908132754.30532-1-tiwai@suse.de> <87sfklgozd.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=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Sep 2022 09:34:30 +0200, Takashi Iwai wrote: > > On Thu, 08 Sep 2022 15:27:54 +0200, > Takashi Iwai wrote: > > > > The dvb-core tries to sync the releases of opened files at > > dvb_dmxdev_release() with two refcounts: dvbdev->users and > > dvr_dvbdev->users. A problem is present in those two syncs: when yet > > another dvb_demux_open() is called during those sync waits, > > dvb_demux_open() continues to process even if the device is being > > closed. This includes the increment of the former refcount, resulting > > in the leftover refcount after the sync of the latter refcount at > > dvb_dmxdev_release(). It ends up with use-after-free, since the > > function believes that all usages were gone and releases the > > resources. > > > > This patch addresses the problem by adding the check of dmxdev->exit > > flag at dvb_demux_open(), just like dvb_dvr_open() already does. With > > the exit flag check, the second call of dvb_demux_open() fails, hence > > the further corruption can be avoided. > > > > Also for avoiding the races of the dmxdev->exit flag reference, this > > patch serializes the dmxdev->exit set up and the sync waits with the > > dmxdev->mutex lock at dvb_dmxdev_release(). Without the mutex lock, > > dvb_demux_open() (or dvb_dvr_open()) may run concurrently with > > dvb_dmxdev_release(), which allows to skip the exit flag check and > > continue the open process that is being closed. > > > > Reported-by: Hyunwoo Kim > > Cc: > > Signed-off-by: Takashi Iwai > > Any review on this? > > FWIW, now CVE-2022-41218 is assigned for those bugs as a security > issue. A gentle ping again. Or if any other fix for this security issue is already available, please let me know. thanks, Takashi > > > thanks, > > Takashi > > > --- > > drivers/media/dvb-core/dmxdev.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c > > index f6ee678107d3..9ce5f010de3f 100644 > > --- a/drivers/media/dvb-core/dmxdev.c > > +++ b/drivers/media/dvb-core/dmxdev.c > > @@ -790,6 +790,11 @@ static int dvb_demux_open(struct inode *inode, struct file *file) > > if (mutex_lock_interruptible(&dmxdev->mutex)) > > return -ERESTARTSYS; > > > > + if (dmxdev->exit) { > > + mutex_unlock(&dmxdev->mutex); > > + return -ENODEV; > > + } > > + > > for (i = 0; i < dmxdev->filternum; i++) > > if (dmxdev->filter[i].state == DMXDEV_STATE_FREE) > > break; > > @@ -1448,7 +1453,10 @@ EXPORT_SYMBOL(dvb_dmxdev_init); > > > > void dvb_dmxdev_release(struct dmxdev *dmxdev) > > { > > + mutex_lock(&dmxdev->mutex); > > dmxdev->exit = 1; > > + mutex_unlock(&dmxdev->mutex); > > + > > if (dmxdev->dvbdev->users > 1) { > > wait_event(dmxdev->dvbdev->wait_queue, > > dmxdev->dvbdev->users == 1); > > -- > > 2.35.3 > >