From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 065EA1DD0E7 for ; Thu, 16 Jan 2025 09:51:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737021097; cv=none; b=KlUYkMIsJQU1mXmVsoA56WeLrnMl7DdBt3Ic5jrg467On6stXC47ln3HFbmWNd8RIW7cJULq+KDLBvKFOwRzNfqK3Ll2K928N6Dg2zDKN5aSpAv04vY5T/J5LBZQ4jlMXZ6ge3a1OwluPd3CNzMLjNwui/4gHEIfSfQiBM9jCZg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737021097; c=relaxed/simple; bh=Wnna+7B3m6qtIVdZpRTIvuVTylF7z37gxByCYJ+zR04=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KMEHIHG0bLsU5yEs+PAg+VoLUc33p/39SKSvDA6snzPCahXAUgAP5R01VVDBM9VRz6Svk6UvvJ5M4b2kMl0D5BO2XD4yhUSvcV+QjOFcM85LQN8LgRrLzLEOLObUVN+Ie/G87EtCyGLVkULg2pDDu4D3aNcQRyJZ7QNWjD5L91k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=xajITNVl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="xajITNVl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41189C4CEE3; Thu, 16 Jan 2025 09:51:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1737021096; bh=Wnna+7B3m6qtIVdZpRTIvuVTylF7z37gxByCYJ+zR04=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xajITNVlK6Zo48A/bEmXjiSf8Jqzk3zirS9bQt6JsiPOn3oavRd2UnoB5bBf8y12M fNT9fEL0ECQHQppQuc/CZFNP1/XdYHMnQf1FzHu6dqz6WGWKDcX/BK/G9BGvFHzIrS 3AYDymHmqrr00lkaA+ZdlYJ0WNDnwPh/xql9DxR0= Date: Thu, 16 Jan 2025 10:51:33 +0100 From: Greg KH To: Tuo Li Cc: tomas.winkler@intel.com, arnd@arndb.de, LKML , Jia-Ju Bai Subject: Re: [BUG] mei: a possible use-after-free caused by concurrency execution Message-ID: <2025011641-seventeen-curse-e404@gregkh> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jan 16, 2025 at 05:26:33PM +0800, Tuo Li wrote: > Hello, > > Our static analysis tool has identified a potential use-after-free caused > by concurrency execution in drivers/misc/mei/main.c. > > Consider the following execution scenario: > (The line numbers can be referred to > https://elixir.bootlin.com/linux/v6.12/source/drivers/misc/mei/main.c) > > mei_release() //Line 112 > cl = file->private_data; //Line 114 > mutex_lock(&dev->device_lock); //Line 123 > kfree(cl); //Line 149 > file->private_data = NULL; //Line 152 > mutex_unlock(&dev->device_lock); //Line 154 > > mei_read() //Line 169 > cl = file->private_data; //Line 172 > mutex_lock(&dev->device_lock); //Line 184 > cb = mei_cl_read_cb(cl, file); //Line 200 > cl_dbg(dev, cl, ...); //Line 275 > mutex_unlock(&dev->device_lock); //Line 276 > > If mei_release() and mei_read() can execute concurrently and the execution > order is 114, 172, 123, 149 (free), 152, 154, 184, 200 (use), 275 (use), > 276, a possible use-after-free can occur. How can release run at the same time read happens? release only happens after all references are dropped, right? > Our static analysis tool reports this use-after-free when analyzing Linux > 6.12. The tool deduces lock() and unlock() pairs with alias analysis. It > then applies data flow analysis to detect use-after-free across > synchronization points. > > I am not quite sure whether this possible use-after-free is real and how to > fix it if it is real. Test it and see! And if you feel a fix is needed, please provide a patch. thanks, greg k-h