Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3327644imu; Sun, 11 Nov 2018 12:28:02 -0800 (PST) X-Google-Smtp-Source: AJdET5dwjNov8Nv5GQSdTLYPytojw+XUn6rHF5M8vHM3yl2UXLLWsS/NhwKkgc7BNz141wTv1cFh X-Received: by 2002:a17:902:b20c:: with SMTP id t12-v6mr1946471plr.249.1541968082219; Sun, 11 Nov 2018 12:28:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541968082; cv=none; d=google.com; s=arc-20160816; b=BpNRnXS1wJu6kssAE75zTz27bELb8zRN3Vz3zyr76tjfiTUOfiYBTeF/iJTRv+IgFI 2ZOlWcWsQyh8Qqci1HkGz8++Zn9F60DZ7SzNrLC/U3a41AkjZVYlW1+aukJF5uSZ/xO3 RMpZ+YJbr/ccgAiEB49aSA8dWzfCYBigNZva9xF0LQDrDlmFW3jsyVwmXsRWySw4shMk YHDIUyw5S/5AP1FUs7J/9TzCIMGePcNduXlX+vKbjeriyGkkjNrcaljvvTBASMtiG53Z OdXORkjpRQQZki2Z6JQQcQzvLdJtwJc65LDCojDvFzaXYKo5Q2+R9lmBrXUoYEn4hZZt vzxQ== 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=gbAsmKyMENJsrrpqs9YrmTkyIqueL+DcwxcB8sZRPCw=; b=Cn9YXB7t+4UYURQbfydAZ2LRtHqrl1YGu58UgLq1NXXxyarY0U3+lgdI3i6ZXP8//D VuFAPurPQJo8D72cx2FRP7lE40oJ5UELi0CrWwTSvvuEAwqlWUtUlgYEqkt14q4jXsf7 aIqtcVVbsOpeIk6loh6whd4eeoApGQ3SlCcRafV4IMLuB1CjLLRqqDIWIM+66KlcuQ1g lk7Hmr/lqesDl3SifeuMgQ894fC16TZASxPk0dFAWT9MVt07JnwasW7Ib0myGyLTXdGj jG/yLUDiAD8YxxL6bbtVKTF1lDaU1+NeMyGor6pCPE7pY+kgq3dwREb1sw/paA8rGUt7 GeBg== 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 59-v6si4287864plb.75.2018.11.11.12.27.46; Sun, 11 Nov 2018 12:28:02 -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 S1731707AbeKLGQ6 (ORCPT + 99 others); Mon, 12 Nov 2018 01:16:58 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50790 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730594AbeKLFs0 (ORCPT ); Mon, 12 Nov 2018 00:48:26 -0500 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 1gLvsk-0000oF-Jw; Sun, 11 Nov 2018 19:58:54 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsY-0001nQ-Nl; Sun, 11 Nov 2018 19:58:42 +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, "Phillip Lougher" , "Anatoly Trosinenko" , "Al Viro" , "Linus Torvalds" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 301/366] squashfs: be more careful about metadata corruption 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.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Linus Torvalds commit 01cfb7937a9af2abb1136c7e89fbf3fd92952956 upstream. Anatoly Trosinenko reports that a corrupted squashfs image can cause a kernel oops. It turns out that squashfs can end up being confused about negative fragment lengths. The regular squashfs_read_data() does check for negative lengths, but squashfs_read_metadata() did not, and the fragment size code just blindly trusted the on-disk value. Fix both the fragment parsing and the metadata reading code. Reported-by: Anatoly Trosinenko Cc: Al Viro Cc: Phillip Lougher Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings --- fs/squashfs/cache.c | 3 +++ fs/squashfs/file.c | 8 ++++++-- fs/squashfs/fragment.c | 4 +--- fs/squashfs/squashfs_fs.h | 6 ++++++ 4 files changed, 16 insertions(+), 5 deletions(-) --- a/fs/squashfs/cache.c +++ b/fs/squashfs/cache.c @@ -350,6 +350,9 @@ int squashfs_read_metadata(struct super_ TRACE("Entered squashfs_read_metadata [%llx:%x]\n", *block, *offset); + if (unlikely(length < 0)) + return -EIO; + while (length) { entry = squashfs_cache_get(sb, msblk->block_cache, *block, 0); if (entry->error) { --- a/fs/squashfs/file.c +++ b/fs/squashfs/file.c @@ -194,7 +194,11 @@ static long long read_indexes(struct sup } for (i = 0; i < blocks; i++) { - int size = le32_to_cpu(blist[i]); + int size = squashfs_block_size(blist[i]); + if (size < 0) { + err = size; + goto failure; + } block += SQUASHFS_COMPRESSED_SIZE_BLOCK(size); } n -= blocks; @@ -367,7 +371,7 @@ static int read_blocklist(struct inode * sizeof(size)); if (res < 0) return res; - return le32_to_cpu(size); + return squashfs_block_size(size); } /* Copy data into page cache */ --- a/fs/squashfs/fragment.c +++ b/fs/squashfs/fragment.c @@ -61,9 +61,7 @@ int squashfs_frag_lookup(struct super_bl return size; *fragment_block = le64_to_cpu(fragment_entry.start_block); - size = le32_to_cpu(fragment_entry.size); - - return size; + return squashfs_block_size(fragment_entry.size); } --- a/fs/squashfs/squashfs_fs.h +++ b/fs/squashfs/squashfs_fs.h @@ -129,6 +129,12 @@ #define SQUASHFS_COMPRESSED_BLOCK(B) (!((B) & SQUASHFS_COMPRESSED_BIT_BLOCK)) +static inline int squashfs_block_size(__le32 raw) +{ + u32 size = le32_to_cpu(raw); + return (size >> 25) ? -EIO : size; +} + /* * Inode number ops. Inodes consist of a compressed block number, and an * uncompressed offset within that block