Received: by 10.223.185.116 with SMTP id b49csp818104wrg; Sat, 10 Feb 2018 21:04:49 -0800 (PST) X-Google-Smtp-Source: AH8x2255+gd7Ah7TNiI0q3S267NkRqQS/chBxNA7A3olIDxakX8B1wg03H5xSZl4mO2pPE0f0Mgq X-Received: by 10.99.95.81 with SMTP id t78mr1434976pgb.380.1518325489271; Sat, 10 Feb 2018 21:04:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518325489; cv=none; d=google.com; s=arc-20160816; b=Q3atvcWAeJVG1k4Wsl2yhy2Lbo3fvYBFfKnXaRo9cnNK2G9UNQSwzE4sVwVUpFh5ud S02awbaH0wfmKm1EP4FTg0AvQ6YBWlzked1exyYuioWgu6kJTcvF8DSxzYBhqLBEICkE B7YRaWQvV+z4fCgC8yeUw87cPoFocdq/30w9LbGxEACOLdHWr/dvrs2qJaQHxQpHDjY0 0WB94TI2J7xsioHh8yMNHd+86TjfBiMw6x/+zK1LuwyuQnSVgnjaPmvgxMbNsrWr3g4V TxKuekWkMY3GShhhHlGW+IQy/C0nm+e5ReFbNMSseYMAWuXQZx0//d0D6if8Kft/PkTN Clbg== 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=1vKiQ66pH3jzkRekLgdiXoHRRmNJcskENWir/+lcGag=; b=ddQG8qLZyf4JNsZNtWAc/YGX7CEh+Cd6UV1itmy7oQheTPZgAu3M3Xy8AGa64zyZAC +7LA6AQtHclVnhX0ASH2IHiv04VSitIXHirO+yO9sqzPKAxKLTGbmHKOPor1S1Hk0ZCs AwDx90R0bn9Mt9WQdAf1D6FCg9QkjsIfwroRKiVeQ7Lm97/bbUexra62//j+Z/V9iHKK JsspicqiMJvbCrdzeOreOc2aQvDkdfVm07tQZ059/niAdN+zGCqTEaztjHb/lIWHeYHf vyJz7yi0YeEEUWWIy3CxdYdSetx2lbarw7cmJz2hLUEQK6CnzqjTMg73TSxfJfzzcI9o rPxw== 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 o18si4295902pfa.407.2018.02.10.21.04.35; Sat, 10 Feb 2018 21:04:49 -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 S1753786AbeBKFEB (ORCPT + 99 others); Sun, 11 Feb 2018 00:04:01 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41528 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752689AbeBKEdn (ORCPT ); Sat, 10 Feb 2018 23:33:43 -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 1ekjKe-0002h9-PR; Sun, 11 Feb 2018 04:33:40 +0000 Received: from ben by deadeye with local (Exim 4.90) (envelope-from ) id 1ekjKX-0004TW-MU; Sun, 11 Feb 2018 04:33:33 +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, "Jan Harkes" , "Al Viro" Date: Sun, 11 Feb 2018 04:20:06 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 26/79] coda: fix 'kernel memory exposure attempt' in fsync 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.2.99-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Jan Harkes commit d337b66a4c52c7b04eec661d86c2ef6e168965a2 upstream. When an application called fsync on a file in Coda a small request with just the file identifier was allocated, but the declared length was set to the size of union of all possible upcall requests. This bug has been around for a very long time and is now caught by the extra checking in usercopy that was introduced in Linux-4.8. The exposure happens when the Coda cache manager process reads the fsync upcall request at which point it is killed. As a result there is nobody servicing any further upcalls, trapping any processes that try to access the mounted Coda filesystem. Signed-off-by: Jan Harkes Signed-off-by: Al Viro Signed-off-by: Ben Hutchings --- fs/coda/upcall.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/fs/coda/upcall.c +++ b/fs/coda/upcall.c @@ -447,8 +447,7 @@ int venus_fsync(struct super_block *sb, UPARG(CODA_FSYNC); inp->coda_fsync.VFid = *fid; - error = coda_upcall(coda_vcp(sb), sizeof(union inputArgs), - &outsize, inp); + error = coda_upcall(coda_vcp(sb), insize, &outsize, inp); CODA_FREE(inp, insize); return error;