Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2351221imm; Thu, 7 Jun 2018 09:11:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJJtLhGVE+P/BbkXtCEw0yMuFij1Z8U9KktldnHIsE9Up8TyRDP+sWOWIjfTY2nqIn2WQV4 X-Received: by 2002:a63:b646:: with SMTP id v6-v6mr2062615pgt.276.1528387912393; Thu, 07 Jun 2018 09:11:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528387912; cv=none; d=google.com; s=arc-20160816; b=U2FyyyxN1xE9UPSzcDkwkzifnKezZxFPUIn2y89kTLJATj4xHMoP7c8ez1O7GN1ULC DP9pi2iQEsH5p5Qtwn4iziarCLhUmygbePBSl2JfLGrUTUReTpiCuxzX6R+1dHuEdURG mAux8+CbWnobUqEvWIKezAyS4grHpZ1cch9OE3YUAyCL9pL56IytMCxUWoVzUT1AKxHH 1dAN0flBxgfhVHsxDibuHFWBrOwvgFMKzPeiPx5+QvfRltY663pTsj5OAuNCH0nUyeLj BhYSDz+0EcYNKvofIu0RDZjx+hIJbnaMY8U7NKc0OV2cEP5WOa/8bQdj3KdL3UwfDT8v oOVg== 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=SK6CDGsmVo8bZCsSxoevHBLh2mHiCmmC9/3zSSen9nc=; b=sK0sCYd1QD2Qsr9UGNn6Mhq+vL40ncZ4WyenLZSHGKOViVkJi/wHO3Y+EdrFQX66Lj Hd17sqp5zYO0+spm/4R6qFnV3XaSsVLE6q0H1PtfUe9iIStX1p6ZW/V22VUsL0JBL+48 BUZfvzfKlMJm/5peY1HiBYqUOM2hpJ0qZmQbDiBCdKm8JJ2p58ezGnc1gX6619NpPfsI 3YgExrqMRCuGJrkJlUMV3xNpBQ5CReSIIXiws3aKJsXzQiMsuELyZLYo8MOVg40To+ft krxNIVmKsQkfuwSTHgBlT2OgkoDbLBBP0YyY+WilBSw5dDJfD8L2A+4mZzNG9gbCnQmC K4NQ== 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 3-v6si55630449plu.564.2018.06.07.09.11.37; Thu, 07 Jun 2018 09:11:52 -0700 (PDT) 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 S934539AbeFGQK2 (ORCPT + 99 others); Thu, 7 Jun 2018 12:10:28 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:39202 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932988AbeFGOJC (ORCPT ); Thu, 7 Jun 2018 10:09:02 -0400 Received: from [148.252.241.226] (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 1fQvb1-0005Zs-Fd; Thu, 07 Jun 2018 15:08:59 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvax-0002hw-QO; Thu, 07 Jun 2018 15:08:55 +0100 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, "=?UTF-8?Q?=E8=8C=83=E9=BE=99=E9=A3=9E?=" , "Takashi Iwai" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 024/410] ALSA: seq: Fix racy pool initializations In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 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.57-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai commit d15d662e89fc667b90cd294b0eb45694e33144da upstream. ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by: 范龙飞 Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings --- sound/core/seq/seq_clientmgr.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -1012,7 +1012,7 @@ static ssize_t snd_seq_write(struct file { struct snd_seq_client *client = file->private_data; int written = 0, len; - int err = -EINVAL; + int err; struct snd_seq_event event; if (!(snd_seq_file_flags(file) & SNDRV_SEQ_LFLG_OUTPUT)) @@ -1027,11 +1027,15 @@ static ssize_t snd_seq_write(struct file /* allocate the pool now if the pool is not allocated yet */ if (client->pool->size > 0 && !snd_seq_write_pool_allocated(client)) { - if (snd_seq_pool_init(client->pool) < 0) + mutex_lock(&client->ioctl_mutex); + err = snd_seq_pool_init(client->pool); + mutex_unlock(&client->ioctl_mutex); + if (err < 0) return -ENOMEM; } /* only process whole events */ + err = -EINVAL; while (count >= sizeof(struct snd_seq_event)) { /* Read in the event header from the user */ len = sizeof(event);