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 305B1C6FA82 for ; Wed, 21 Sep 2022 07:34:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230163AbiIUHeh (ORCPT ); Wed, 21 Sep 2022 03:34:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229776AbiIUHef (ORCPT ); Wed, 21 Sep 2022 03:34:35 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16BE72DC5; Wed, 21 Sep 2022 00:34:32 -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 C6B951F855; Wed, 21 Sep 2022 07:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1663745670; 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=Ngk+vqgXw4fEPdzeT+fxWlhQ7jSVECUeUmMrxCjYSYg=; b=H+2uRRD9PfFSbHIvu3xVORDGuyyfHOSQ4ooYlfBTl7Ifoo70Y5nVnvD37s7bXV4Fx+Ce1g lR0gx/1ccqT5XPX1kbDqjbPzK0r/aA2V64DUYEARXEZAqpoI13U/1AXmN5hbYGkQcAD0Sy Vy4d4MRihaUCl5xpM8cJ/nLy75oply8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1663745670; 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=Ngk+vqgXw4fEPdzeT+fxWlhQ7jSVECUeUmMrxCjYSYg=; b=q7H9NVjUFOKwfJwOGVoJeWqX3QMJbOPswQErGyf2TRtW5Yjl1dU7plWHnDdaqn8e7vadpe GThZn016MvjcE7Ag== 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 A99E513A00; Wed, 21 Sep 2022 07:34:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 60e9KIa+KmMkDwAAMHmgww (envelope-from ); Wed, 21 Sep 2022 07:34:30 +0000 Date: Wed, 21 Sep 2022 09:34:30 +0200 Message-ID: <87sfklgozd.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: <20220908132754.30532-1-tiwai@suse.de> References: <20220908132754.30532-1-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 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. 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 >