From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A79A3C433E3 for ; Fri, 21 Aug 2020 00:42:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6A595208E4 for ; Fri, 21 Aug 2020 00:42:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="oxLmkQuv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A595208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 151F98D0024; Thu, 20 Aug 2020 20:42:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 102EE8D001E; Thu, 20 Aug 2020 20:42:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F33FE8D0024; Thu, 20 Aug 2020 20:42:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id DE26C8D001E for ; Thu, 20 Aug 2020 20:42:13 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A0B07362F for ; Fri, 21 Aug 2020 00:42:13 +0000 (UTC) X-FDA: 77172724146.03.low12_2107c6c27035 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 73C8428A4E8 for ; Fri, 21 Aug 2020 00:42:13 +0000 (UTC) X-HE-Tag: low12_2107c6c27035 X-Filterd-Recvd-Size: 3328 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 00:42:12 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DF7522087D; Fri, 21 Aug 2020 00:42:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597970532; bh=OlGxIascbHIUZun41BFql3oNdYaebmCmIUt072WhhrM=; h=Date:From:To:Subject:In-Reply-To:From; b=oxLmkQuvJRdiZDxiY5OHxzBOiaY/Su417hN6czHfJjEPqJEkspjDGBrRcnHPoiBzm wcAPhwKEIQ9McnXR+47hCY2RAKurR4xe5IPp1brYlIdnb1KWhBVK1Zg27lWxezTtop cRyyYi/F0JjlltFPlqMwGiait+F/+miw1GOeFDn4= Date: Thu, 20 Aug 2020 17:42:11 -0700 From: Andrew Morton To: akpm@linux-foundation.org, dhowells@redhat.com, gregkh@linuxfoundation.org, jannh@google.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 06/11] romfs: fix uninitialized memory leak in romfs_dev_read() Message-ID: <20200821004211.g7aXs16ZQ%akpm@linux-foundation.org> In-Reply-To: <20200820174132.67fd4a7a9359048f807a533b@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Queue-Id: 73C8428A4E8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Jann Horn Subject: romfs: fix uninitialized memory leak in romfs_dev_read() romfs has a superblock field that limits the size of the filesystem; data beyond that limit is never accessed. romfs_dev_read() fetches a caller-supplied number of bytes from the backing device. It returns 0 on success or an error code on failure; therefore, its API can't represent short reads, it's all-or-nothing. However, when romfs_dev_read() detects that the requested operation would cross the filesystem size limit, it currently silently truncates the requested number of bytes. This e.g. means that when the content of a file with size 0x1000 starts one byte before the filesystem size limit, ->readpage() will only fill a single byte of the supplied page while leaving the rest uninitialized, leaking that uninitialized memory to userspace. Fix it by returning an error code instead of truncating the read when the requested read operation would go beyond the end of the filesystem. Link: http://lkml.kernel.org/r/20200818013202.2246365-1-jannh@google.com Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly") Signed-off-by: Jann Horn Reviewed-by: Greg Kroah-Hartman Cc: David Howells Cc: Signed-off-by: Andrew Morton --- fs/romfs/storage.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/fs/romfs/storage.c~romfs-fix-uninitialized-memory-leak-in-romfs_dev_read +++ a/fs/romfs/storage.c @@ -217,10 +217,8 @@ int romfs_dev_read(struct super_block *s size_t limit; limit = romfs_maxsize(sb); - if (pos >= limit) + if (pos >= limit || buflen > limit - pos) return -EIO; - if (buflen > limit - pos) - buflen = limit - pos; #ifdef CONFIG_ROMFS_ON_MTD if (sb->s_mtd) _