Received: by 10.223.185.116 with SMTP id b49csp6383594wrg; Wed, 28 Feb 2018 08:31:10 -0800 (PST) X-Google-Smtp-Source: AH8x224RqznHwZXS6N7UV0pmgONJozzYWLH2HjjnkrkzeuJTdLsjxLXqNSrvZqV+5xwosX+YeXou X-Received: by 2002:a17:902:26a:: with SMTP id 97-v6mr18699344plc.3.1519835470013; Wed, 28 Feb 2018 08:31:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519835469; cv=none; d=google.com; s=arc-20160816; b=dOx0zYwxcEM9bArwzQ9/DatvzQA/IVSasezCi6mh/CegWu7XOozkHjSnM9d0bApHSK eaADErA25z5vBK0I73xpKzFNkizuvk28c9bJveB1xzBvvZM2VNgJdfNF2NoslgmPY2Xy IQNMqk+UdRVQwitsbytzE6Rs4dlx5vlBjWIsp2nBKp5Q8Isd4ihzgzGXzRfq1h1xvhi1 KdzbrSmedRzdICBEa/piR681VqkGrjNlWLwkLhU2XBC2cvySY7mvhsM/VK0NHTphhOkx YkYxhRYoKRaDHnRwDI8AGEenCDRXB4umPTc0W7q490jJKVLUiozebUV3tAOfkBukYIiL wCrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=Sa+ICi0zGMD19VtYg1Xf17OsNRFR+RxK2xnp3J7RASw=; b=Zt2aLK7Eu93rGmAmsCB2GrZMDXQsO1jYlGYcv9dg9AwAH6jdkaVnO2Yvbi0iGCaZ/A bxj5T7bbXUq8V8prdEfAhvWSpwCImjbhDNOe19nW4+wfbz/+y7RlXUKWuRPtYL8JGAsl UPJ3xjKYcymZUugfOZnA98G43EIeR8PbM1Y+/7jQGp05pi8begmg98OC+Rapmq20SkXY MylXTP3ot4vYLOUCY+/xEYzj7WZz0utnuk+ifrA90I34P87vuT08Vc/TfasY4Q807UEp D6haemectQdya1hRtITGg0ZmSCSZYBf1QQ8tGbwo6zfcc3wLARroloXQYE/3lxfkl5HS 7eTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1-v6si1517467pld.401.2018.02.28.08.30.55; Wed, 28 Feb 2018 08:31:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934773AbeB1QPL (ORCPT + 99 others); Wed, 28 Feb 2018 11:15:11 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35155 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934746AbeB1QPI (ORCPT ); Wed, 28 Feb 2018 11:15:08 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Ys-0006Xe-HF; Wed, 28 Feb 2018 15:22:30 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yg-00005z-MP; Wed, 28 Feb 2018 15:22:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Takashi Iwai" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 113/254] ALSA: rawmidi: Avoid racy info ioctl via ctl device In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai commit c1cfd9025cc394fd137a01159d74335c5ac978ce upstream. The rawmidi also allows to obtaining the information via ioctl of ctl API. It means that user can issue an ioctl to the rawmidi device even when it's being removed as long as the control device is present. Although the code has some protection via the global register_mutex, its range is limited to the search of the corresponding rawmidi object, and the mutex is already unlocked at accessing the rawmidi object. This may lead to a use-after-free. For avoiding it, this patch widens the application of register_mutex to the whole snd_rawmidi_info_select() function. We have another mutex per rawmidi object, but this operation isn't very hot path, so it shouldn't matter from the performance POV. Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings --- sound/core/rawmidi.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) --- a/sound/core/rawmidi.c +++ b/sound/core/rawmidi.c @@ -589,15 +589,14 @@ static int snd_rawmidi_info_user(struct return 0; } -int snd_rawmidi_info_select(struct snd_card *card, struct snd_rawmidi_info *info) +static int __snd_rawmidi_info_select(struct snd_card *card, + struct snd_rawmidi_info *info) { struct snd_rawmidi *rmidi; struct snd_rawmidi_str *pstr; struct snd_rawmidi_substream *substream; - mutex_lock(®ister_mutex); rmidi = snd_rawmidi_search(card, info->device); - mutex_unlock(®ister_mutex); if (!rmidi) return -ENXIO; if (info->stream < 0 || info->stream > 1) @@ -613,6 +612,16 @@ int snd_rawmidi_info_select(struct snd_c } return -ENXIO; } + +int snd_rawmidi_info_select(struct snd_card *card, struct snd_rawmidi_info *info) +{ + int ret; + + mutex_lock(®ister_mutex); + ret = __snd_rawmidi_info_select(card, info); + mutex_unlock(®ister_mutex); + return ret; +} EXPORT_SYMBOL(snd_rawmidi_info_select); static int snd_rawmidi_info_select_user(struct snd_card *card,