From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-1511654-1518325442-2-10619353637072245694 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.001, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='uk', MailFrom='org' X-Spam-charsets: plain='UTF-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: stable-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1518325442; b=WpFar/pGm+ImKTnUK+UE8znF/238jPauz+w9CWpHHSd721X yqe9L0mSaCKboIY3MOqMP4kdGWM/K1zz7vLkvSN6A5ZpkykPerbsLGDUpvvS8gxm nlfz88YV1kSWiQpLK/e4Avifd/GACwd5O0sqSmuW1Y+MYIVS2HzzhkjBmnYqiBfs vwen6SBXtS/yBTNWek9wUTQhJUtWhiptAv7ewdW9tgciWwyPe5T0cBkuzCyrUz6f JyYOgjaGFoUb79B9n562DCP9DacdcjNIAmaDid1QZNvEFf0Rsgh0nUo2hpqPmQFB 0BRX68tLA1hr05pJ9HxgnUb9yddoz1q50sXNDog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:content-transfer-encoding :mime-version:from:to:cc:date:message-id:subject:in-reply-to :sender:list-id; s=arctest; t=1518325442; bh=1vKiQ66pH3jzkRekLgd iXoHRRmNJcskENWir/+lcGag=; b=Dyxer/xDb6oj/t9wbjpFjLPKFJ4I4xAOjug 6rTUpeumkTe2iqhgTkEiF1ijgTgtntYEh9GbB1HbeGBiU/bjIOQ6QjUjS70ggIrb ZhIN1KHoSzpp8JjYY3m91zY/i7BonnuvD3VnqEpYcnpc/yKYxq9LkOwaoz+8iXUG bCe0ia43s8+IhuYe3ky8v43+1DS1g6n8XH0zywi1XxdcLmjv0qqgigSOlXsiZygl V6cr0mgsiCGmp5aVJKKsOpYPM7hhJwcQmB6TelilkES3reDh+BQYDRNFPUWKEIza tdT3TCwrtnPuY0K5dEjhVXuooT3ee/O+PjAvwGStG50LZgVi2Tg== ARC-Authentication-Results: i=1; mx6.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=decadent.org.uk; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=decadent.org.uk header.result=pass header_is_org_domain=yes Authentication-Results: mx6.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=decadent.org.uk; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=decadent.org.uk header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753659AbeBKFD6 (ORCPT ); Sun, 11 Feb 2018 00:03:58 -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 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: stable-owner@vger.kernel.org X-Mailing-List: stable@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 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;