Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2338200ybz; Thu, 23 Apr 2020 16:17:47 -0700 (PDT) X-Google-Smtp-Source: APiQypIa71gZjjgn2OqH+ellsxuKME/iwt4Gi3FodXlwWhMNmPd8uqInQU2+LkIevLBFAgQaA6At X-Received: by 2002:a50:c20a:: with SMTP id n10mr5143101edf.319.1587683867037; Thu, 23 Apr 2020 16:17:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683867; cv=none; d=google.com; s=arc-20160816; b=X6HK8d/kNHrq7cooHKpyF9rQlRdGvVSj4hDqk4lp/QgT3cLmbAxGnKzwtvxn94qVAN I2G5Qk41d/2aqu2YBimSlQWYpB+OsC9HraRCZsG8EPIEsNmrmReGAkzXALkqpA3+UQCW 2P1tgZeZ99NwU6o9FR7SPH6BQtGniJ84Y7mLvbMGXhT4NnwVSSwrCkJ3f/Zp4zzl/dWe QET7Ky8Kb42MZ2jNSAR/kUdb+PXTEREOpdBEx+CKpjMEMRJ6ju/ChGx5y0g3FHCVyqFS S8Tv+w1156SyCov1pCOlqQjHc8gCN48JDmwJrHneMcU1cmE2bnL1nGpvCrpCm2Fl9/N2 l44w== 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; bh=Au+TMV2DqdeqgRlS/MBYdsH3edNIF1pDyT0FzpIHC98=; b=qqniud0fJwkM7g7ZbPf7Or3UMvB84KyQbIx8xcFlbouACK0q+lxhK4qSTHm5fHg0Mm LmQSdXBb2MQiqzckVgGCltdMMje25WUklcZF/Bl0yHdPQCzVIR1ZsKAzlr7RuLL0x0Wg 14slay8NvludaO2AK6z53fwnfsUQovDMyPgP+ESDOXggDgHfrgIaF1qFbXCzFDmF4O3j HmsLzYYMtP8dbvM8P1KJuTJXyv0LQTu+Ec4SLdWLlCDb8SBoNhnJHcNIvGC9zMlo7V8y P3IiSqFYWGias0TvyoKU5EMewFPSdQktISTcajdr6nIcgk10WFg44a2PX0jtBOJFsPS1 aQag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ks15si2140275ejb.223.2020.04.23.16.17.22; Thu, 23 Apr 2020 16:17:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729077AbgDWXOp (ORCPT + 99 others); Thu, 23 Apr 2020 19:14:45 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49822 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728443AbgDWXGs (ORCPT ); Thu, 23 Apr 2020 19:06:48 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvV-0004hq-CD; Fri, 24 Apr 2020 00:06:37 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvR-00E6pF-CI; Fri, 24 Apr 2020 00:06:33 +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, Denis Kirjanov , "Lionel Koenig" , "Greg Kroah-Hartman" , "Takashi Iwai" Date: Fri, 24 Apr 2020 00:05:54 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 127/245] ALSA: pcm: Avoid possible info leaks from PCM stream buffers In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 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.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Takashi Iwai commit add9d56d7b3781532208afbff5509d7382fb6efe upstream. The current PCM code doesn't initialize explicitly the buffers allocated for PCM streams, hence it might leak some uninitialized kernel data or previous stream contents by mmapping or reading the buffer before actually starting the stream. Since this is a common problem, this patch simply adds the clearance of the buffer data at hw_params callback. Although this does only zero-clear no matter which format is used, which doesn't mean the silence for some formats, but it should be OK because the intention is just to clear the previous data on the buffer. Reported-by: Lionel Koenig Link: https://lore.kernel.org/r/20191211155742.3213-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings --- sound/core/pcm_native.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -459,6 +459,10 @@ static int snd_pcm_hw_params(struct snd_ while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size) runtime->boundary *= 2; + /* clear the buffer for avoiding possible kernel info leaks */ + if (runtime->dma_area) + memset(runtime->dma_area, 0, runtime->dma_bytes); + snd_pcm_timer_resolution_change(substream); snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);